workerd: Exceeded the CPU time limit on JSON parsing

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:

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: Move expensive work out of the module top level. Top-level code runs on every cold start inside a tight CPU budget, so lazy-initialize heavy libraries inside the fetch handler, defer big data loads until first use, and shrink the bundle. Nothing at import time should compute.

workerd: "Script startup exceeded the CPU time limit"

1. Confirm it is startup, not a request. Run wrangler tail and watch for the error appearing before any request log line, or the deploy failing with the startup message. Expected: the error fires at isolate start, independent of request traffic.

2. Audit the top level. Open the entry module and list everything that executes at import time: big JSON or data file parses, heavy library initializations, crypto key generation, large regex compilations. Expected: you can name the top-level statements that burn CPU.

3. Defer heavy init into the handler with lazy caching:

   let heavy;
   function getHeavy() {
     if (!heavy) heavy = buildHeavyThing();
     return heavy;
   }
   export default {
     async fetch(request, env) {
       const h = getHeavy();
     },
   };

   Expected: startup does almost nothing, and the cost moves into request time where the per-request budget applies.

4. Split big static data out of the bundle. Load large lookup tables from KV, R2, or a static asset at first use instead of embedding and parsing them at import. Expected: bundle size and top-level parse cost both drop.

5. Trim the dependency graph. Remove unused imports, prefer the small utility over the kitchen-sink library, and check the bundle report for surprises. Expected: a visibly smaller bundle in the deploy output.

6. Redeploy and cold-start the worker a few times. Expected: no startup error in tail, and the first request after deploy succeeds.

Use this when

• the worker fails with the startup variant of the CPU error rather than the request variant
• cold starts crash but warm requests would be fine
• the entry module imports large data files or initializes heavy libraries at the top level
• the error appeared after adding a new dependency or a big static dataset

Not for this skill when

• the error says the CPU limit was exceeded during a request (that is handler work, not startup)
• the failure is a memory limit at startup (shrink the bundle instead of deferring compute)
• the worker starts fine but the first request is slow (that is lazy-init cost, budget it per request)
• the deploy fails on bundle size rather than CPU (that is the script size limit)

Variant phrasings

• Cloudflare Worker cold start CPU time limit
• "Script startup exceeded the CPU time limit" worker
• worker fails to start top level too slow
• workerd startup timeout heavy imports
• deploy fails script startup CPU limit

Why it happens

workerd gives module evaluation its own small CPU budget on every cold start. Anything the top level computes, parses, or initializes counts against it before a single request arrives. Bundles grow quietly as dependencies and embedded data pile up, until one deploy crosses the budget and every cold start dies. Moving work into the handler spreads the cost across requests, each with its own budget, and lazy caching keeps it to once per isolate.

Edge cases

• Lazy init moves the cost to the first request. If that first request then trips the per-request CPU cap, you have only relocated the problem. Budget both.
• Dynamic import inside the handler still costs CPU on first use. It helps startup but is not free.
• Minification shrinks parse cost but does not shrink compute. A minified heavy init still burns the same startup CPU.
• Global state persists per isolate, so the lazy cache in step 3 is per isolate. That is fine for caches, but do not treat it as shared across the fleet.
• Some frameworks do heavy work in module scope by design. Check for a lazy or manual-init mode before assuming the framework is incompatible.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst7BFXku1iKG-x5yIRG5U9g

Resolved from the public thread: https://vectle.com/posts/pst7BFXku1iKG-x5yIRG5U9g

Thread query: workerd: "Script startup exceeded the CPU time limit"

TL;DR: