How to Fix Cloudflare Error 1019 (Compute Server Error)

By ErrorFix · Updated October 26, 2026 · 7 min read

What Error 1019 means

Cloudflare's 1xxx error family covers DNS, proxy, and compute configuration problems, and Error 1019 is the compute entry in that family. Cloudflare's own documentation describes it in one line: a compute server error related to a Cloudflare Worker, whose common cause is a Worker script that recursively references itself. The page carries HTTP status 503, which is why the site looks completely down rather than partly broken — no version of the page can load while the loop is in place.

Picture the loop in slow motion. A visitor requests a page, Cloudflare routes the request to the Worker, and the Worker code fetches a URL in order to build its response. If that URL is one the Worker itself handles, Cloudflare routes the fetch right back to the same Worker, which fetches the same URL again, and again. Cloudflare detects the recursion and serves Error 1019 instead of letting the loop run forever. Nothing about your computer, browser, or internet connection causes this, and nothing on the visitor's side can resolve it. Only someone who can edit and redeploy the Worker can break the cycle. It is also worth distinguishing 1019 from its close relatives: Error 1101 means a Worker threw a JavaScript exception, Error 1102 means a Worker exceeded its CPU or memory limit, and Error 1014 means a CNAME points across Cloudflare accounts — none of those is a self-calling loop.

Common causes

• Worker fetches its own public hostname: the most common trigger. A Worker attached to example.com fetches https://example.com/api or a similar path to get data, and that fetch routes through the Worker again instead of going straight to the origin server.
• Relative fetch that resolves through the Worker: calling fetch with a path like /data or /api inside a Worker, without a full origin URL, so the request is resolved against the Worker's own hostname and re-enters the Worker.
• Redirect or rewrite back to a Worker-handled route: a Worker that redirects, rewrites, or proxies a request to a URL its own route pattern catches. Each pass through the Worker issues the same redirect again, so the request never escapes.
• Two Workers calling each other in a circle: Worker A fetches a route handled by Worker B, and Worker B fetches a route handled by Worker A. Neither Worker calls itself directly, but together they form the same endless loop.
• Middleware, helper, or service binding that re-enters the Worker: an authentication check, logging helper, or service binding that issues its own fetch to a Worker-handled URL on every request. The main handler looks innocent, while a shared helper quietly restarts the loop on each pass.

How to fix Error 1019 — step by step

Steps 1 through 5 are for the developer or site owner. Step 6 is for visitors.

1. Recognize that Error 1019 is a Worker recursion problem. Recognize that Error 1019 is a Worker recursion problem, not a visitor problem. Cloudflare serves Error 1019, a compute server error with HTTP status 503, when a Worker script recursively references itself. No browser setting, cache clear, or device change can fix it, because the loop lives in the Worker's own code. Visitors should skip to step 6; the middle steps are for the developer or site owner who controls the Worker.
2. Open the Worker and check its logs for repeated requests. Open the Worker and check its logs for repeated requests. In the Cloudflare dashboard, go to Workers and Pages, select the Worker that serves the broken route, then open Logs. Look for the same request path appearing over and over in a tight burst, or a single request that spawns many subrequests before failing. That repeating pattern is the fingerprint of a recursive loop, and the path that repeats tells you which route is calling itself.
3. Find the fetch call that points back at the Worker's own route. Find the fetch call that points back at the Worker's own route. Search the Worker source for fetch calls, and check each one against the Worker's own hostname and route pattern. The culprit is usually a fetch to the same hostname the Worker is attached to, a fetch to a relative path that resolves through the Worker again, or a redirect that sends the request back to a URL the Worker handles. Also check any middleware, helper function, or chained Worker that the request passes through, because the loop can hide one hop away from the main handler.
4. Break the loop by fetching the origin directly or guarding the request. Break the loop by fetching the origin directly or guarding the request. The cleanest fix is to point the fetch at the origin server itself, such as the origin hostname or IP that sits behind Cloudflare, instead of at the public hostname that routes through the Worker. If the Worker must call a Cloudflare-fronted URL, add a guard: send a custom header or query marker on the internal fetch and return early, or serve the origin response directly, when that marker is present, so the second pass never fetches again. Never let a Worker fetch a URL that its own route pattern will catch a second time.
5. Redeploy the Worker and verify the site loads again. Redeploy the Worker and verify the site loads again. Deploy from the dashboard, or from your terminal with npx wrangler deploy, then request the broken URL in a fresh browser tab and watch the Worker logs for a single clean request instead of a burst. If the page still shows Error 1019, purge the cache in the Cloudflare dashboard under Caching, then Configuration, then Purge Everything, because a cached copy of the error page can keep showing after the code is fixed. Repeat the log check until one request produces one fetch, not a chain.
6. Visitor: report it to the owner and retry later. Visitor: report it to the owner and retry later. As a visitor you cannot fix Error 1019, because the recursive Worker belongs to the site owner. Reload the page once to rule out a cached error, then reach the owner through their other channels: social media accounts, a contact email, or their support system. Tell them you are seeing Cloudflare Error 1019, a compute server error caused by a Worker calling itself, which tells them exactly where to look. Try the site again after a few hours; once the owner breaks the loop and redeploys, the site loads normally.

Did this fix it? Quick checklist

• No fetch in the Worker points at a URL the Worker's own route pattern handles
• The Worker logs show one clean request per visitor request, not a burst of repeats
• The internal fetch goes to the origin directly, or a guard stops the second pass
• After redeploying and purging the Cloudflare cache, the site loads instead of the Error 1019 page

If you are the owner and the error persists after the obvious fetch looks fixed, search the whole Worker project, not just the main handler — shared helpers, middleware, and chained Workers are the usual hiding places for a second fetch. Also check the route pattern itself: a broad pattern such as a catch-all route will swallow fetches you expected to bypass the Worker, so narrow the pattern or move the internal endpoint outside it. And if the Worker was recently deployed from a new branch or a new team member's change, compare that deploy with the last working one; a single changed fetch target is often the whole story, and rolling back to the last good deploy while you investigate is a legitimate short-term fix.