Error 1102 — Worker exceeded CPU time or memory limit
Cloudflare Error 1102 means your Worker exceeded its CPU time budget (10ms on the Free plan, up to 30s on Workers Paid) or its 128MB memory limit. The runtime kills the isolate instantly — no graceful shutdown, no SDK call, no error handler. This is one of the hardest crashes to debug because your code never gets a chance to log what happened.
Common causes
- ▸Heavy synchronous CPU work: bcrypt/scrypt password hashing (common with better-auth and @noble/hashes), JSON schema validation, large regex, or recursive parsers
- ▸Building a large array or object in memory (e.g., loading an entire CSV or JSON file into a single variable)
- ▸Memory leak: accumulating data in a global variable across requests (Workers persist globals within an isolate)
- ▸Processing large responses without streaming: fetch().then(r => r.text()) on a 100MB+ response buffers the entire body
- ▸Infinite loop that allocates memory: while(true) { arr.push(...) }
- ▸Caching too much data in the global scope instead of using KV or Durable Objects
Symptoms
- •Intermittent 500 errors on CPU-intensive or memory-heavy endpoints (auth, file processing, AI calls)
- •Cloudflare dashboard shows 'Error 1102' but no stack trace
- •The error happens on large requests or heavy auth flows but not on simple GETs
- •Your Worker works fine in wrangler dev (Node.js has 1.5GB memory and no per-request CPU cap) but crashes in production
- •Memory usage climbs over time if you have a module-scope leak
How to fix it
- ✓Use Web Crypto (crypto.subtle) instead of pure-JS bcrypt/scrypt — Web Crypto runs natively and doesn't count against your CPU budget the same way
- ✓Raise the CPU limit on Workers Paid ($5/mo): you can configure limits up to 30 seconds per request in wrangler.jsonc
- ✓Stream large responses instead of buffering: use response.body (ReadableStream) and TransformStream to process chunks as they arrive
- ✓Avoid global-scope caching — move shared state to KV, Durable Objects, or the Cache API
- ✓Limit array sizes: if (arr.length > 10000) throw new Error('Too many items')
- ✓Use pagination for large datasets instead of loading everything at once
- ✓Deploy a Tail Worker (like FlareLog) to capture CPU/OOM crashes — you'll see the request that triggered the kill even though your code never logged it
How FlareLog helps
When your Worker hits a CPU or memory limit, the runtime kills it instantly — your SDK never fires. FlareLog's Tail Worker runs out-of-band, after your Worker finishes (or crashes), and receives the execution outcome from Cloudflare's runtime — including the OOM/CPU event, CPU time consumed, and the full request context. You see which request triggered the kill, which endpoint is the hot path, and how close you are to the limit. This is the only way to debug Error 1102 without guessing.
Catch Error 1102 with FlareLog →FAQ
Why does my Worker work locally but crash with Error 1102 in production?
wrangler dev runs on Node.js, which has a default 1.5GB memory limit and no per-request CPU cap. Cloudflare Workers have a strict 128MB memory limit and a 10ms CPU budget on the Free plan (configurable up to 30s on Paid). Code that works fine locally can OOM or CPU-time-out in production. Always test CPU-intensive endpoints (auth, AI, file processing) with realistic payloads, and deploy a Tail Worker so you catch these crashes before users do.
How do I raise the Cloudflare Workers CPU time limit?
On the Workers Paid plan ($5/month, includes 10M requests), you can configure the CPU limit per Worker in wrangler.jsonc using the `limits.cpu_ms` field, up to a maximum of 30,000ms (30 seconds). The Free plan is hard-capped at 10ms and cannot be raised. If you're hitting CPU limits on auth flows (bcrypt, scrypt, Argon2), switch to Web Crypto (crypto.subtle) which runs natively and is far cheaper per operation.
Why doesn't Sentry catch Error 1102?
Sentry's Cloudflare Workers SDK wraps your fetch handler and calls captureException on thrown errors. But Error 1102 happens when the runtime kills the isolate — your fetch handler is terminated mid-execution, so captureException never fires. Sentry sees nothing. FlareLog's Tail Worker runs after the kill and receives the execution outcome from Cloudflare's runtime, so it captures CPU/OOM crashes that happen before, during, or after your code runs.
Does streaming help with Error 1102?
Yes, for memory-related 1102s. Instead of `await response.text()` (buffers the entire body in memory), use `response.body` (a ReadableStream) and process chunks as they arrive. This keeps memory usage flat regardless of response size. Use TransformStream to modify streaming data without buffering. For CPU-related 1102s, streaming won't help — you need to reduce per-request CPU work or raise the CPU limit.
How do I find a memory leak in my Worker?
Workers persist global-scope variables within an isolate. If you're pushing to a global array or caching in a global Map, it grows indefinitely as the isolate handles more requests. Search your code for `const` or `let` at module scope that accumulates data. Move shared state to KV or Durable Objects. FlareLog's Tail Worker can alert you when OOM crashes increase over time — a telltale sign of a leak.