Skip to content

Fixing Workers CPU time limit exceeded (Error 1102)

Covers genuine CPU-time exhaustion (heavy synchronous computation) and distinguishes it from a request that's merely slow because it's waiting on a subrequest — waiting time never counts toward CPU time, so that case needs a different fix entirely. Does not cover memory-limit resets (a different error, "Exceeded Memory") or the free-plan daily request cap (Error 1027).

Cloudflare WorkersWrangler
Unverifiedno reproductions yetWhy this confidence?
Revision 1published by DevYou curationrevision history
Run the diagnosisEvidence and compatibility

Symptoms

The diagnostic path

8 steps. Every step is written out below in full — the interactive version simply follows the branches for you.

  1. Step 1 · StartWorker times out only in production

    The Worker fails with Error 1102 in production while the same code path never times out locally under wrangler dev. CPU time (active execution) is capped by the platform; wrangler dev does not enforce that same cap, which is exactly why this only reproduces once deployed.

    What happens next

    • passed → step 2, Confirm it's CPU time, not a request timeout

  2. Step 2 · TestConfirm it's CPU time, not a request timeout

    Check the invocation outcome for this request. exceededCpu (Error 1102) means active CPU execution ran past the configured limit; anything else (a plain timeout or 524) is a different problem.

    Read-onlysh
    npx wrangler tail --format json

    Expected result

    The trace event's outcome field is "exceededCpu".

    What happens next

    • passed → step 3, Profile the hot path and/or raise the CPU limit
    • failed → step 4, Check whether it's actually a slow await, not CPU work
    • unknown → step 3, Profile the hot path and/or raise the CPU limit

  3. Step 3 · FixProfile the hot path and/or raise the CPU limit

    Use CPU profiling (DevTools via wrangler dev --remote or the dashboard) to find the expensive synchronous section — a large loop, heavy JSON processing, or a hashing/compression routine. Optimise it, and if the workload genuinely needs more headroom, raise the configured limit; Workers Paid supports up to 300,000 ms (5 minutes) per request, up from the 30-second default.

    Changes statejsonc

    Changes system or service state. Review before running.

    Raises the Worker's maximum CPU time per request from the default 30 seconds up to 300 seconds. It does not make inefficient code faster — it only gives it more room before being killed — and the higher value is only honoured on the Workers Paid plan.

    {
  "limits": {
    "cpu_ms": 300000
  }
}

    What happens next

    • passed → step 5, Re-run the same production request path

  4. Step 4 · TestCheck whether it's actually a slow await, not CPU work

    Time spent waiting on a fetch(), D1 query, or KV read never counts toward CPU time — only active execution does. If the request is slow because it's waiting on a downstream call, raising cpu_ms will not help.

    Read-onlysh
    npx wrangler tail --format json

    Expected result

    A large gap between wallTime and cpuTime in the trace event — most of the elapsed time was spent waiting, not computing.

    What happens next

    • passed → step 6, This is a latency problem, not a CPU-time problem
    • failed → step 7, Not resolved — escalate
    • unknown → step 7, Not resolved — escalate

  5. Step 5 · Verify the fixRe-run the same production request path

    Repeat the request that previously failed and confirm the invocation outcome is no longer exceededCpu.

    Read-onlysh
    npx wrangler tail --format json

    Expected result

    outcome: "ok" for the same request path.

    What happens next

    • passed → step 8, Resolved
    • failed → step 7, Not resolved — escalate
    • unknown → step 7, Not resolved — escalate

  6. Step 6 · FixThis is a latency problem, not a CPU-time problem

    The fix here is optimising or parallelising the slow downstream call (the D1/KV/fetch you're awaiting), or moving the work to a Durable Object/Queue for background processing — not raising cpu_ms, which only affects active computation and won't touch wait time.

    What happens next

    • passed → step 5, Re-run the same production request path

  7. Step 7 · EndNot resolved — escalate

    If neither profiling nor raising the limit clears exceededCpu, and it isn't a wait-time issue either, capture a CPU profile and the Ray ID and take it to Cloudflare Support.

  8. Step 8 · EndResolved

    The request now completes within its CPU time budget.

Sources

Why this confidence?

What would strengthen it: 6 more independent reproductions. Reproductions from 3 more distinct environments.