Error 1027 — Worker exceeded memory limit
Cloudflare Error 1027 means your Worker exceeded the 128MB memory limit. The runtime kills the Worker immediately — 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
- ▸Building a large array or object in memory (e.g., loading an entire CSV or JSON file)
- ▸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 200MB response)
- ▸Infinite loop that allocates memory (while(true) { arr.push(...) })
- ▸Circular references in objects passed to JSON.stringify()
- ▸Caching too much data in the global scope instead of using KV or Durable Objects
Symptoms
- •Intermittent 500 errors on memory-intensive endpoints
- •Cloudflare dashboard shows 'Error 1027' but no stack trace
- •The error happens on large requests but not small ones
- •Your Worker works fine in wrangler dev (Node.js has more memory) but crashes in production
- •Memory usage climbs over time if you have a memory leak
How to fix it
- ✓Stream large responses instead of buffering: use response.body (ReadableStream) and transform streams
- ✓Avoid global-scope caching — use KV, Durable Objects, or Cache API for shared state
- ✓Limit array sizes: if (arr.length > 10000) throw new Error('Too many items')
- ✓Use pagination for large datasets instead of loading everything at once
- ✓Profile memory usage locally with wrangler dev --local and Node's --inspect flag
- ✓Deploy a Tail Worker (like FlareLog) to capture memory-related crashes — you'll see the request that triggered OOM even though your code didn't log it
How FlareLog helps
When your Worker hits the 128MB limit, the runtime kills it instantly — your SDK never fires. FlareLog's Tail Worker receives the execution outcome (including the OOM event) from Cloudflare's runtime. You see which request triggered the memory spike, how much CPU time was used before the kill, and the full request context. This is the only way to debug Error 1027 without guessing.
Catch Error 1027 with FlareLog →FAQ
Why does my Worker work locally but crash with Error 1027 in production?
wrangler dev runs on Node.js, which has a default 1.5GB memory limit. Cloudflare Workers have a strict 128MB limit. Code that works fine locally can OOM in production. Always test memory-intensive endpoints with realistic data sizes, and deploy a Tail Worker so you catch OOM crashes before users do.
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. 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.
Does streaming help with memory limits?
Yes. 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.