If error 1019 appears after a Worker deployment or route change, trace where its outgoing request goes. Cloudflare documents recursive self-reference as a common cause: the destination invokes the same Worker again. Compare the intended request path with the actual route and any redirects before changing WordPress.
Guide reviewed: October 8, 2026. Interface labels may vary by version, account and device.
Find where the request returns to the same Worker
| Check | Evidence | What it reveals |
|---|---|---|
| Incoming address | Worker route or custom domain | Which script starts handling the request |
| Outgoing destination | Hostname and path used by the script | Whether it returns to the same script |
| Redirect destination | Observed onward addresses | An indirect return to the caller |
| Recent changes | Code and route configuration separately | Whether restoring code also restores routing |
Draw the intended path and the actual path
Write two short sequences: the intended flow might be visitor → Worker → hosting origin → response. A failing flow may instead be visitor → Worker → public Worker hostname → the same Worker. This is a diagnostic illustration; confirm the actual route coverage and redirects in your setup before choosing a destination.
Start with the address that displays 1019 and the Worker attached to it. In the Worker code, identify the outgoing request made while handling that address. Then check which route or custom domain will handle the destination.
For example, a Worker might be intended to read a page from the hosting server, adjust its response, and return it to the visitor. If its destination is a public hostname attached to the same Worker, the actual path returns to the beginning. The hostname can look like the correct site address while still being the wrong destination for this part of the design.
A simple note showing “visitor, Worker, intended server” beside the observed route helps the maintainer spot the difference. It is easier to review than a large list of unrelated WordPress settings.
Inspect route coverage and outgoing requests together
A route that covers many paths can capture a destination the developer expected to be outside the Worker. Review both the hostname and path when checking that coverage. Changing only the final path may leave the request within the same broad route.
Also review any redirect encountered while reaching the destination. The outgoing address may appear separate initially, while a later response sends the request back toward the public hostname. Keep the full observed path in the investigation rather than stopping at the first URL in the code.
If the loop began after a deployment, compare the outgoing destination and route configuration with the previous version. Either can change the request path. A code rollback will not necessarily undo a route adjustment made separately in the dashboard.
Give the request a destination that can finish
For a call to another Worker, review the supported service connection with the developer. For a hosting origin, use the established origin-routing arrangement. The repair needs a destination that completes the request while retaining any access decisions and response processing the original design requires.
The documented repair is to ensure the Worker does not access a URL that calls the same script. How to achieve that depends on the intended service. A WordPress hosting origin and an internal Worker service are different destinations and should be configured accordingly.
For a conventional origin, use the hosting and routing arrangement supported by your setup. Do not expose a private endpoint or remove an access check merely to produce a different URL. If the target is another Worker, review the supported connection between the services instead of treating its public address as automatically suitable.
Keep the change focused and reversible. The developer should be able to explain where the outgoing request goes after the repair and why it no longer comes back to the caller. That explanation is the useful design check.
Test the complete response, including other affected paths
Open the original failing page and confirm that the expected WordPress content appears. Review the Worker logs for the same test so that the observed result can be linked to the request you changed.
Try a second page under the route, and include a relevant signed-in or form workflow if the Worker handles it. A public article working is reassuring, but it does not prove that every response transformation still behaves correctly.
If a different error replaces 1019, keep the new message. Breaking the loop may reveal an origin connection or application issue that was previously hidden. Investigate that next stage with its own evidence instead of restoring the recursive route.
For support, provide the Worker name, sanitized outgoing destination, route or custom-domain configuration, failure time, and recent deployment changes. Keep tokens and private request headers out of shared examples. These details let the maintainer reconstruct the loop without needing unrelated WordPress content.
Documenting the final request path is useful beyond this repair. It gives future maintainers a clear boundary between the public Worker address and the destination it must reach to finish serving a page.
Reference: Cloudflare error 1019 documentation.
Confirm the loop ended without losing behavior
Test the original page and another matching path, then compare logs for those requests. Confirm any affected form or signed-in workflow. If a different error emerges, record it as the next stage of the investigation. Keep a diagram of the final request path with the deployment notes.