Cloudflare Error 1101: Worker Threw Exception

Problem

A page served through a Cloudflare Worker returns Error 1101: Worker threw exception (or “Rendering error”). The request reached Cloudflare’s edge, the Worker ran, and the Worker’s own code failed before it could return a response.

Symptoms

• The Cloudflare error page shows 1101 with “Worker threw exception,” not a 520–526 origin error.
• HTTP Check returns a Cloudflare-branded 5xx page for the URL, and the failure is reproducible from any network.
• It fails on some routes or some inputs but not others — a specific path, a specific query string, a logged-in user.
• Your origin server logs show nothing, because the request never left the edge.

What 1101 Actually Means

A Worker is not a proxy in front of your app — for the routes it owns, the Worker is the app, running in Cloudflare’s edge runtime. So 1101 is not a networking problem. It is your JavaScript throwing an uncaught exception, rejecting a promise nobody caught, or — the sneaky variant — finishing all its work without ever calling back with a Response.

That last case has a distinct signature. Cloudflare’s runtime reports “the script will never generate a response” when all the code tied to the request has run, the event loop is empty, and still no Response came back. The usual culprit is an await on a promise that never resolves or rejects: a fetch() to a subrequest that hangs, a binding you forgot to await, a dangling new Promise with no path to resolve.

This is the whole reason 1101 gets misdiagnosed. It looks like a 5xx, so people go hunt for a down server. But the 520–524 codes mean Cloudflare talked to your origin and disliked the answer. 1101 means there was no origin conversation at all — the edge code crashed. Chasing the origin is looking under the wrong streetlight.

Top 3 Causes

1. An uncaught exception on a specific code path - The Worker throws on one route, one input shape, or one branch — a JSON.parse on a malformed body, an array index that goes undefined, a .map on something that isn’t an array. The happy path works, so it slipped past testing, and only production traffic hits the bad branch. This is why 1101 is often intermittent, not total.
2. A missing or misnamed binding - The code reads env.MY_KV or env.DB, but the binding was never added to the deployment, or the name in wrangler.toml doesn’t match the name in the code. The reference is undefined, the first method call on it throws, and every request that touches it 1101s.
3. A promise that never settles - A subrequest fetch() to a slow or dead upstream that you await without a timeout, or a hand-rolled promise with a missing resolve. The Worker doesn’t throw — it just never returns, and the runtime surfaces “the script will never generate a response.”

Diagnose with DechoNet

• HTTP Check to confirm the 1101 is deterministic. If our automated request to the failing URL also comes back with the Cloudflare error every time, the exception fires on that request shape — reproduce it locally with the same method, path, and headers. If HTTP Check succeeds while one specific path fails for you, the bug is route- or input-specific, and that exact request is what you feed to wrangler tail.
• DNS Check to confirm the hostname is actually proxied through Cloudflare (orange-clouded) so you know a Worker is even in the path — a grey-clouded record skips Workers entirely and rules 1101 out.

Resolution Checklist

• Read the actual exception. Run wrangler tail (or open Workers real-time logs in the dashboard) and reproduce the request. The stack trace shows up under the exceptions field — that line number is your bug.
• Reproduce it deterministically. Note the exact route, method, and payload that triggers the 1101 from HTTP Check, then replay it against wrangler dev locally.
• Audit every binding. Confirm each env.* the code reads is declared in wrangler.toml with the identical name, and that KV/D1/R2 bindings exist in the deployed environment, not just locally.
• Wrap risky work in try/catch and add timeouts. Guard JSON.parse, external fetch(), and anything that parses user input, and never await a subrequest without an abort timeout so a dead upstream can’t hang the whole Worker.
• Rule out 1102 and 1027 first. If the message is “exceeded resource limits,” you have a CPU/memory problem, not a crash; if it’s “daily request limit exceeded,” you are out of Free-plan quota until midnight UTC. Neither is fixed by editing logic.
• Redeploy and keep tailing. Push the fix, watch the exceptions field stay empty under real traffic, and only then call it closed.

When to Escalate

• If wrangler tail shows no exception at all but requests still 1101, capture the request ID (Ray ID) from the error page and open a Cloudflare ticket — a runtime-side issue is rare but does happen, and the Ray ID lets them trace that exact request.
• If the exception traces into a third-party library or SDK bundled into the Worker, escalate to that package’s maintainers with the stack trace; edge runtimes lack some Node APIs, and a library assuming Node globals will throw in ways your own code never would.