Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
If a Cloudflare Worker exceeds its CPU limit, first determine whether the error happened while handling an invocation or while Cloudflare was validating a deployment. For an invocation overrun, check CPU time in Workers Logs or a trace before changing the design: optimize the hot path, split work into bounded chunks, offload computation, or—on a plan that allows it—increase the configured CPU limit. Splitting is useful when work can safely be divided; it does not remove Cloudflare’s limits.
First identify which CPU error you have
Cloudflare has two similar-sounding errors with different causes and fixes.
Runtime invocation: Error 1102
A Worker that exceeds runtime resource limits can return Error 1102, “Worker exceeded resource limits.” The message can indicate CPU or another resource constraint, so do not diagnose a CPU overrun from that text alone. Look for the dashboard status “Exceeded CPU Time Limits” or the exceededCpu indicator in analytics or Logpush, and correlate it with the invocation’s logs. Cloudflare’s Workers limits documentation describes the CPU limit and runtime remedies; its errors and exceptions documentation explains error reporting.
Deployment validation: Error 10021
If deployment fails with “Script startup exceeded CPU time limit” or validation error 10021, the issue is top-level startup work—not the CPU used by a normal request. Cloudflare documents a one-second startup CPU limit. Inspect code that runs during initialization, such as expensive global-scope setup, and move work to build time or into the request handler where appropriate. Cloudflare’s error documentation distinguishes validation errors from runtime errors.
#1 Best Overall
CPU time is not the same as elapsed time
Cloudflare defines CPU time as time spent executing Worker code. Waiting for a network request—including fetch(), a KV read, or a database query—does not count toward the CPU total. A slow upstream response can therefore make a request take a long time without consuming equivalent CPU time. Cloudflare’s limits documentation covers this distinction.
HTTP invocation duration has no hard limit while the client remains connected, but the CPU allowance still applies. Other triggers have documented wall-time ceilings: Queue consumers, Cron Triggers, and Durable Object alarms are limited to 15 minutes. A long-running request is not, by itself, proof of a CPU overrun.
Measure the invocation before choosing a fix
Workers Logs include CPU and wall time. Tail Workers and Logpush expose CPU time in trace events, and DevTools CPU profiling can help locate the code consuming it. Compare CPU with wall time: high elapsed time with relatively little CPU points toward waiting, while CPU near the applicable allowance points toward computation. Cloudflare documents these observability options in its Workers limits guide.
Cloudflare cites about 2.2 ms as average CPU per request across Workers, and says heavier workloads such as authentication, server-side rendering, or large-payload parsing typically use 10–20 ms. These are broad figures from Cloudflare, not a prediction for any particular application; profile your own Worker before deciding that a workload is unusually expensive.
Check the limit for your plan and trigger
Cloudflare’s limits documentation, last updated September 5, 2026, lists the following CPU allowances. HTTP CPU limits and Cron CPU limits are separate; do not apply an HTTP figure to a Cron invocation.
| Trigger and plan | Documented CPU allowance |
|---|---|
| HTTP request, Workers Free | 10 ms per request |
| HTTP request, Workers Paid | 30 seconds by default; configurable up to five minutes (300,000 ms) |
| Cron Trigger, Workers Free | 10 ms per invocation |
| Cron Trigger, Workers Paid; schedule interval under one hour | 30 seconds per invocation |
| Cron Trigger, Workers Paid; schedule interval of at least one hour | 15 minutes per invocation |
These are Cloudflare-published limits, not application measurements. Check the current Workers limits documentation for your trigger and plan before changing configuration.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Choose a remedy based on the measured cause
Optimize a specific CPU-heavy path
If profiling points to a hot path, reduce avoidable computation there. This is the most direct remedy when the same work can be done more efficiently within one invocation. Start from the profile rather than assuming that network latency, a particular library, or the entire handler is responsible.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →Split work when it has natural boundaries
Chunking can help when a task can be divided into bounded pieces and continued across invocations. Persist progress between chunks, keep each invocation within its applicable CPU limit, and design the work so retries do not duplicate or corrupt results. These are implementation safeguards, not automatic guarantees provided by Cloudflare. Splitting can add latency and coordination overhead, so it is a poor fit for work that must complete as one indivisible operation.
Offload expensive computation
When computation is too costly or unsuitable for the request path, move it to a more appropriate execution path or process it in smaller units. Cloudflare lists offloading expensive computation and processing smaller chunks across requests among its remedies; choose based on the workload and the limits of the trigger you use.
Raise the configured allowance when appropriate
Workers Paid HTTP requests have a 30-second CPU default and can be configured up to 300,000 ms (five minutes), according to Cloudflare’s current limits documentation. A higher ceiling gives an invocation more CPU time; it does not make the code more efficient or eliminate platform limits. Cloudflare’s March 26, 2025 announcement said the default would remain 30 seconds and described opting in through the cpu_ms setting. Consult the current limits guide for configuration details; the historical announcement is at Cloudflare’s five-minute CPU-time announcement.
Quick Recap
A practical decision path
- Classify the failure: distinguish runtime Error 1102 and the “Exceeded CPU Time Limits” status from deployment validation error 10021.
- Inspect evidence: use Workers Logs, trace events through Tail Workers or Logpush, and DevTools CPU profiling to compare CPU time with wall time and find the hot path.
- Match the fix to the cause: address computation when CPU is high; investigate waiting or I/O when wall time is high but CPU is not.
- Pick a safe execution shape: optimize one invocation, chunk work with persisted progress and retry-safe behavior, or offload computation.
- Adjust configuration only if it fits: verify that the plan and trigger support the needed allowance, then decide whether a larger per-invocation budget is preferable to redesigning the job.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
