workerd: "Script startup exceeded the CPU time limit"

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.

1. 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.

1. 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.

1. 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.

1. 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.

1. 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