workerd: Script startup exceeded the CPU time limit

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:

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: 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: