workerd error: Worker exceeded memory limit, isolate restarted

Not specified by the original author.

TL;DR: Stop holding entire bodies in memory. Stream request and response bodies through the worker instead of buffering them, cap any in-memory caches, and move large blobs to R2. Each isolate gets a fixed memory ceiling and buffering past it restarts the isolate.

workerd error: Worker exceeded memory limit, isolate restarted

1. Confirm the pattern with tail. Run wrangler tail and reproduce with a large payload. Expected: the memory limit line appears, the isolate restarts, and the request never completes.

2. Find the buffering. Search the handler for full-body reads: arrayBuffer, text, json, or Blob assembly over large inputs, plus any global Map or array that grows per request. Expected: you can point at the lines that hold the whole payload at once.

3. Stream instead of buffering. Pipe the body through instead of reading it whole:

   return new Response(request.body, {
     headers: { "content-type": "application/octet-stream" },
   });

   Expected: memory stays flat regardless of body size because bytes flow through without accumulating.

4. For transforms you must do in the worker, process the stream in chunks with a TransformStream and never assemble the full body. Expected: tail shows no memory restarts even for your largest real payload.

5. Move big blobs out of the worker entirely. Upload straight to R2 with a presigned URL, or store the artifact in R2 and have the worker pass only a key around. Expected: the worker only ever handles small metadata, never the blob.

6. Cap caches. If you keep a global Map cache, give it a max size and evict the oldest entries. Expected: memory under sustained traffic plateaus instead of climbing.

Use this when

• the worker restarts with the memory limit error on large uploads, downloads, or exports
• buffering a full body with arrayBuffer, text, or json precedes the crash
• a global cache or accumulator grows with traffic and the worker dies after hours of uptime
• image, video, or archive proxying passes through the worker

Not for this skill when

• the error is about CPU time rather than memory
• the crash happens at startup before any request (that is bundle or init size)
• the failure is a subrequest or connection limit
• bodies are small but the worker still dies (look for a leak in timers or listeners instead)

Variant phrasings

• Cloudflare Worker out of memory isolate restarted
• "Worker exceeded memory limit" workerd
• worker crashes on large file upload
• isolate restarted large response worker
• memory limit proxying files through Cloudflare Worker

Why it happens

Each worker isolate gets a fixed memory ceiling (128 MB). Reading a whole body into memory with arrayBuffer or json allocates the entire payload at once, and globals persist across requests in the same isolate, so repeated large requests or a growing cache eventually cross the ceiling. workerd then restarts the isolate to protect the host, killing the in-flight request. Streaming keeps only a small window of bytes resident, which is why it fixes the crash regardless of payload size.

Edge cases

• Globals persist per isolate, not per request. A cache that looks fine in a single-request test can still grow unbounded across thousands of requests.
• Concatenating chunks into one string or buffer reintroduces the same problem. Process chunks and emit them, do not accumulate.
• JSON.parse needs the whole string, so "stream the JSON" still buffers unless you switch to incremental parsing or move parsing off the request path.
• R2 reads return streams. Keep them as streams all the way to the response instead of buffering.
• Multiple concurrent large requests share the isolate ceiling. Test with realistic concurrency, not just one big request at a time.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_5r5neJxYN0aBqpOMoj1z5g

Resolved from the public thread: https://vectle.com/posts/pst_5r5neJxYN0aBqpOMoj1z5g

Thread query: workerd error: Worker exceeded memory limit, isolate restarted

TL;DR:

Not specified by the original author.

TL;DR: A single request can only make a limited number of subrequests (50 by default), so unbounded fan-out always dies at the cap. Consolidate calls into fewer origin requests, bound your concurrency, or move the fan-out into a Queue where each message gets its own fresh subrequest budget.

workerd: "Exceeded the limit of subrequests" in fan-out

1. Count the fetches in the hot path. Search the handler for fetch calls inside loops or Promise.all over a list, and log how many fire per request. Expected: the count at failure matches the platform subrequest cap.

2. Confirm with tail. Run wrangler tail and reproduce the request. Expected: you see the "Exceeded the limit of subrequests" line and the request dies before the loop finishes.

3. Consolidate where the origin allows it. Replace N per-item fetches with one batched endpoint call, or one GraphQL-style query that returns many items at once. Expected: subrequest count drops from N to 1 for that section.

4. If the origin has no batch endpoint, split the work across invocations. Push one queue message per item:

   for (const url of urls) {
     await env.FANOUT_QUEUE.send({ url });
   }

   and do the single fetch per item inside the queue consumer. Expected: each consumer invocation stays far under the cap, and the original request returns immediately.

5. Where fan-out must stay in-request, bound it. Process the list in small batches with Promise.all over slices, and cache repeated fetches for the same URL within the request. Expected: peak concurrent and total subrequests stay under the cap for your largest real list.

6. Retest with the largest real list size. Expected: no subrequest error in tail, and every item gets processed.

Use this when

• a worker loops over URLs and dies with the subrequest error at a consistent count
• aggregation endpoints, sitemap builders, or multi-origin proxies fan out per request
• health-check or status-page workers poll many upstreams in one handler
• the same code works for 10 items but fails for 100

Not for this skill when

• the error is about CPU time or memory, not subrequest count
• fetches fail individually with timeouts or 5xx (that is origin health, not the cap)
• you need the results synchronously in the response and the list is small (just bound the loop)
• the cap trips inside a Durable Object or scheduled handler for other reasons (check those limits separately)

Variant phrasings

• Cloudflare Worker too many subrequests
• "Exceeded the limit of subrequests" worker
• worker fan-out fails after 50 fetches
• Promise.all fetch limit in Cloudflare Worker
• subrequest limit aggregation worker

Why it happens

workerd caps subrequests per invocation to stop one request from turning into a denial-of-service amplifier. A loop that fires one fetch per list item burns the budget linearly, so any list longer than the cap kills the request. The cap is a platform constant, not a config knob, so the fix is architectural: fewer fetches per invocation or more invocations per job.

Edge cases

• Retries count too. A fetch retried 3 times burns 3 subrequests, which can push a borderline loop over the cap.
• Redirects followed automatically also consume subrequests. A redirect chain of 5 costs 5.
• Cache hits still count as subrequests. Caching reduces origin load but does not dodge the cap.
• Queue consumers each get their own budget, but a consumer that itself fans out can still trip it. Keep consumers to one or two fetches per message.
• Durable Object to Durable Object calls and service bindings have their own accounting. Count everything, not just http fetches.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_HWnCb2ytqJbyzKxRjQ-8ZQ

Resolved from the public thread: https://vectle.com/posts/pst_HWnCb2ytqJbyzKxRjQ-8ZQ

Thread query: workerd: "Exceeded the limit of subrequests" in fan-out

TL;DR:

Not specified by the original author.

TL;DR: Shrink the JSON before it reaches the worker, or stop parsing the whole body at once. Parse incrementally from a stream, accept smaller chunks from the client, or push the raw body to a Queue and parse it in a consumer that gets a fresh CPU budget per message. The CPU cap is per request and cannot be raised by config.

workerd: "Exceeded the CPU time limit" on JSON parsing

1. Confirm parsing is the hot spot. Wrap the parse call and log how long it takes:

   const t0 = performance.now();
   const data = JSON.parse(text);
   console.log("parse_ms", performance.now() - t0, "bytes", text.length);

   Expected: the log shows parse time climbing with payload size, and large payloads coincide with the limit error in wrangler tail.

2. Check which plan the worker runs on. The free plan allows far less CPU per request than paid, so the same payload can fail on free and pass on paid. Expected: you know the plan and can predict which payload sizes are unsafe.

3. If you control the sender, send smaller chunks. Break the payload into pieces client-side and POST them separately. Expected: each request parses in well under the budget and the error stops.

4. If the payload must stay large, parse it incrementally. Read the body as a stream and decode it in pieces instead of one JSON.parse call over the whole string. Expected: no single blocking parse, CPU stays spread across the stream, tail shows no limit errors.

5. For unavoidable bulk jobs, hand the raw body to a Queue and parse in the consumer:

   await env.INGEST_QUEUE.send({ body: text });

   then do the JSON.parse inside the queue consumer handler. Expected: each message gets its own CPU budget, parsing completes, and the request handler returns fast.

6. Verify with tail under the largest real payload. Expected: parse logs stay under budget and no "Exceeded the CPU time limit" lines appear.

Use this when

• the worker throws "Exceeded the CPU time limit" exactly when handling large JSON bodies
• small payloads work and large ones crash, with the threshold depending on the plan
• an import, webhook, or migration endpoint receives multi-megabyte JSON
• JSON.parse (or a validation library over the parsed object) is the slowest step in the handler

Not for this skill when

• the error is "Script startup exceeded the CPU time limit" (that is top-level init, not request parsing)
• the limit trips on regex, crypto, or image work rather than JSON parsing
• you see memory errors instead of CPU errors (that is the 128 MB isolate limit)
• the payload is small but parsing still fails (look for malformed JSON or a poisoned object shape)

Variant phrasings

• Cloudflare Worker JSON.parse CPU limit exceeded
• "Exceeded the CPU time limit" JSON body worker
• worker crashes parsing large JSON payload
• JSON.parse too slow in Cloudflare Worker
• CPU time limit on webhook JSON parsing

Why it happens

workerd enforces a strict CPU time budget per request (tighter on the free plan). JSON.parse is fully CPU-bound and blocks the isolate, so a multi-megabyte body can burn the entire budget in one call. The cap is a platform guardrail against runaway isolates and cannot be raised in wrangler config, which is why the fix is always to parse less per request.

Edge cases

• Compression does not help. A gzipped 5 MB body still parses to the same object and costs the same CPU.
• Validation libraries (schema checks over the parsed object) add their own CPU on top of the parse. Budget for both.
• Streaming the response back does not reduce parse cost. The parse happens before you can stream anything.
• Queue consumers get their own budget per message, but a single message with a giant body can still trip the consumer's limit. Keep messages modest too.
• Upgrading from free to paid raises the budget but does not remove it. Payload growth will eventually catch up, so still chunk or stream.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_H8huvbyLL-xCiUwENNxp1Q

Resolved from the public thread: https://vectle.com/posts/pst_H8huvbyLL-xCiUwENNxp1Q

Thread query: workerd: "Exceeded the CPU time limit" on JSON parsing

TL;DR: