Cloudflare Error 1102: Worker Exceeded Resource Limits

Problem

A page served by a Cloudflare Worker returns Error 1102: Worker exceeded resource limits. The Worker ran — this is not a networking failure and not a thrown exception — but a single invocation used more CPU time or more memory than its plan allows, and the runtime stopped it.

Symptoms

• The Cloudflare error page shows 1102 “Worker exceeded resource limits,” not 1101 (exception), 1027 (daily limit), or a 520–526 origin error.
• HTTP Check returns the Cloudflare 1102 page for the URL, reproducible from any network.
• It fails on heavy inputs — a large request body, a big JSON payload, a long list to render — while small requests to the same route succeed.
• It fails on the first request after a deploy (a cold start) but then works, if heavy work runs in global scope during isolate startup.
• No stack trace anywhere, because nothing threw.

What 1102 Actually Means

A Worker gets a strict resource budget per invocation, and 1102 is the runtime enforcing it. There are two separate budgets, and the fix depends on which one you hit.

CPU time. This is time spent executing code — loops, JSON.parse, crypto, regex, building strings. Crucially, time spent waiting on the network does not count: a fetch() to a slow upstream can take two seconds of wall-clock and still cost almost no CPU. The Free plan caps CPU at 10 ms per request. That is small, and it is the most common 1102 trigger: parsing a large JSON body, running an unbounded loop, or doing heavy templating tips a Free Worker over 10 ms on exactly the requests with the most data. The Paid plan defaults to 30 seconds and can be raised to 5 minutes for genuinely CPU-bound tasks.

Memory. Each isolate gets 128 MB, on both Free and Paid. Buffer a large request or response body into memory, hold big objects in global scope, or accumulate rows into an ever-growing array, and you cross it. When an isolate exceeds 128 MB, Cloudflare lets in-flight requests finish and spins up a fresh isolate; under sustained overrun, incoming requests get dropped as 1102 to keep the edge stable.

The reason 1102 gets misdiagnosed as 1101 is that both render as a Cloudflare error page over a Worker route. But 1101 has a stack trace and 1102 does not — nothing threw, the code was working, it just cost too much. If you go hunting for an exception on a 1102 you will not find one, because the bug is a hot loop or a fat allocation, not a crash.

Top 3 Causes

1. A hot code path on Free’s 10 ms budget - The Worker parses a large JSON body, runs a loop whose size scales with input, or does synchronous crypto/compression on the request. Small inputs stay under 10 ms; large ones blow past it. This is why 1102 is usually input-dependent, not total — the same route works and fails depending on payload size.
2. Buffering a large body into memory - Reading a whole request or response body into a string or array instead of streaming it. A single large upload or a big upstream response pushes the isolate past 128 MB. Streaming the body through, instead of await response.text() on something huge, is the fix.
3. Heavy work in global scope (cold-start 1102) - Expensive initialization at module top level — building a large lookup table, parsing a bundled dataset, importing a heavyweight library — runs during isolate startup and counts against CPU. It 1102s the first request that warms a new isolate, then “mysteriously” works. Move the work behind lazy initialization or precompute it at build time.

Diagnose with DechoNet

• HTTP Check to confirm the 1102 is real and reproducible from outside your network, and to see whether it correlates with request size — fire the failing route with a small payload and a large one. If small succeeds and large 1102s, you have a CPU or memory scaling problem tied to input, not a steady-state failure.
• DNS Check to confirm the hostname is actually proxied through Cloudflare (orange-clouded) so a Worker is even in the path. A grey-clouded record skips Workers entirely and rules 1102 out.

Resolution Checklist

• Confirm the message says “exceeded resource limits,” not “threw exception” (1101) or “daily request limit exceeded” (1027). The three have unrelated fixes.
• Read CPU time per invocation in Workers Logs (or wrangler tail). CPU time is surfaced in the invocation log — find the route or input shape that spikes it.
• If you are on Free and CPU-bound, either optimize the hot path (fewer loop iterations, cheaper parsing, cache computed values, offload heavy compute) or move to Paid and raise the CPU limit.
• For memory, stop buffering large bodies — stream request/response through instead of reading them whole, drop big objects out of global scope, and don’t accumulate unbounded arrays.
• For cold-start 1102, move expensive top-level initialization behind lazy init or precompute it at build time so it doesn’t run during isolate startup.
• Redeploy and re-run HTTP Check with both small and large inputs to confirm the ceiling is no longer hit.

When to Escalate

• If CPU time and memory both look well within budget in the logs but requests still 1102, capture the Ray ID from the error page and open a Cloudflare ticket — a runtime-side measurement issue is rare but the Ray ID lets them trace that exact invocation.
• If the cost traces into a bundled third-party library (a heavyweight parser, a crypto or image library not built for edge runtimes), escalate to that package or replace it — some libraries assume server-grade CPU and memory and will never fit a 10 ms / 128 MB envelope.