Splitting a job into smaller pieces fixes a Worker CPU overrun only when the time is spent executing your code and the work can be divided safely. Before you restructure anything, confirm which error you are seeing, since a runtime invocation overrun and a deployment-time startup error have different causes and different fixes. Then measure where the CPU time goes.
Start by identifying which error you are seeing
Cloudflare Workers report CPU problems in two different places. A runtime invocation overrun happens while a request, Cron run, or other trigger is executing. A startup error happens when a deployment loads your script. The table below shows how to tell them apart.
As an Amazon Associate I earn from qualifying purchases.
| Item | Runtime invocation overrun | Startup error at deployment |
|---|---|---|
| When it happens | During a request or scheduled invocation | When the script is deployed and its top-level code runs |
| How it is reported | Error 1102, “Worker exceeded resource limits”; dashboard status “Exceeded CPU Time Limits”; exceededCpu in analytics and Logpush |
Deployment validation error 10021, “Script startup exceeded CPU time limit” |
| CPU allowance | Set by plan and trigger (see the limits table below) | One second for top-level startup work |
| Typical cause | Too much computation per invocation | Expensive initialization in global scope |
| First step | Check the invocation status and logs | Find module-level code that runs at load |
Error 1102 covers resource limits in general, so the message alone does not prove the cause is CPU. Confirm with the “Exceeded CPU Time Limits” status or the exceededCpu field. The Cloudflare errors and exceptions documentation describes how validation and runtime errors differ.
Recommended Free Tools
What counts toward CPU time
Cloudflare’s Limits documentation (last updated September 5, 2026) defines the term directly: “CPU time measures how long the CPU spends executing your Worker code. Waiting on network requests (such as fetch() calls, KV reads, or database queries) does not count toward CPU time.”
That distinction decides most diagnoses. Parsing a large payload, running loops over records, transforming JSON, or doing heavy string work all consume CPU. A fetch() that takes two seconds to return consumes wall time, not CPU time, unless your code is busy while it waits.
Wall time has its own rules. HTTP invocations have no hard duration limit while the client stays connected, but that does not lift the CPU limit. Queue consumers, Cron Triggers, and Durable Object alarms have a documented 15-minute wall-time ceiling. A job can therefore run for a long time in wall time while staying well inside its CPU budget, or fail on CPU while finishing quickly in wall time.
Current CPU limits by plan and trigger
The figures below come from the Cloudflare Workers limits documentation, last updated September 5, 2026. Check that page before you rely on them, since limits can change.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
| Trigger | Workers Free | Workers Paid |
|---|---|---|
| HTTP request | 10 ms CPU per request | 30 seconds default; configurable up to 5 minutes (300,000 ms) |
| Cron Trigger, schedule interval less than one hour | 10 ms CPU per Cron Trigger | 30 seconds per invocation |
| Cron Trigger, schedule interval one hour or more | 10 ms CPU per Cron Trigger | 15 minutes per invocation |
On Paid plans, the 30-second HTTP default can be raised through the cpu_ms setting, up to 300,000 ms. Cloudflare’s March 26, 2025 announcement said the default stayed at 30 seconds and that cpu_ms opts in to a higher limit. The original announcement is historical context; the current limits page is the authority for present values.
Cloudflare also publishes typical usage. It reports about 2.2 ms average CPU per request, and says heavier workloads such as authentication, server-side rendering, or large-payload parsing typically use 10 to 20 ms. These are Cloudflare’s published figures, not predictions for your Worker. Because the heavier range sits close to the 10 ms Free allowance, a Free-plan Worker that does this kind of work has little headroom.
Measure before you change the design
- Confirm the error class. In the Worker’s dashboard status or in logs, look for “Exceeded CPU Time Limits” or
exceededCpuon the failing invocations. If you see only a startup message, skip to the startup section below. - Compare CPU and wall time for failing invocations. Workers Logs record both values. If wall time is high and CPU time is well under the limit, the invocation is waiting on I/O and splitting the code will not address the cause. If CPU time is near or above the limit, continue.
- Use trace data for patterns across many runs. Tail Workers and Logpush expose CPU time in trace events, which helps you find which triggers or routes cross the limit most often.
- Profile the hot path. Record a CPU profile of the Worker code with DevTools and find the functions that consume the most CPU. Do this on a representative input, because a small test payload can hide the problem.
- Choose a remedy using the comparison below.
Choose the remedy that matches the work
Cloudflare’s official remedies are to raise the CPU limit where your plan allows it, profile and optimize the code, or offload expensive computation and process smaller chunks across requests. The table compares them on the factors that usually decide the choice.
| Factor | Optimize the hot path | Split into chunks | Raise the configured allowance |
|---|---|---|---|
| Best fit | A specific function dominates CPU time | Work is a batch of independent items | Work is occasionally heavy and cannot be reduced |
| Needs progress storage | No | Yes, between invocations | No |
| Main cost | Engineering time and code changes | More invocations, added latency, retry logic | More CPU consumed per invocation |
| Does not fix | Work that is inherently large per item | A single item that exceeds the limit | Wasteful code; it hides the cost rather than removing it |
Optimize the hot path first
Profiling often shows repeated work rather than unavoidable work: the same body parsed twice, lookup tables rebuilt on every request, or a sort run inside a loop. Removing this waste is usually the cheapest fix and keeps the architecture intact. Build reusable lookup structures once, but keep heavy setup out of global scope, because startup has its own one-second allowance.
Split the job into bounded chunks
Splitting works when the job is naturally divisible, such as importing a list of records, processing a queue of independent items, or paginating through a dataset. Each invocation handles a fixed batch that fits its CPU budget, saves a cursor or offset to durable storage, and hands the next batch to another invocation.
Make retries safe before you rely on the pattern. Write results idempotently, for example keyed by record ID, so a batch that runs twice does not apply its changes twice. Track which batches have completed so a failure restarts only the affected batch. Cloudflare’s guidance is to process smaller chunks across requests; the persistence and retry design are engineering choices you must implement yourself, not something the platform guarantees.
Splitting does not remove the limit. Every chunk still has its own CPU allowance. If one item alone takes longer than the allowance, make that item cheaper or move its computation elsewhere. Smaller batches also add latency, because the job now needs several invocations to finish.
Raise the configured allowance only when it fits
On Paid plans you can set cpu_ms up to 300,000 ms. This buys more CPU per invocation, which is reasonable when the work is legitimately heavy and cannot be reduced. It does not make the code cheaper. Cloudflare’s March 26, 2025 announcement states the reason the default is kept low: “By default, Workers are still limited to 30 seconds of CPU time. This protects developers from incurring accidental cost due to buggy code.” A higher allowance means a runaway loop can consume more resources before it stops, so raise the limit only after profiling shows the cost is real.
When the error is a startup failure
- Confirm that the deployment reports “Script startup exceeded CPU time limit” or error 10021. These are validation errors, not invocation overruns.
- Find code that runs when the module loads, such as large data parsing, precomputed tables, or heavy setup executed at the top level of the file.
- Move that work to build time, or into the handler so it runs per request and is counted against the normal invocation limit. Then redeploy and confirm the error is gone.
Troubleshooting branches
- CPU is low but wall time is high: The invocation is waiting on a dependency. Fix the slow call, add timeouts, or move the wait out of the request path. Splitting the CPU work will not help.
- One function dominates the profile: Optimize it first. Split only if the function’s cost scales with the number of items.
- A single item exceeds the limit: Splitting cannot fix this. Optimize that item or raise the configured allowance if the plan supports it.
- Chunks still fail after splitting: Reduce the batch size and check per-invocation CPU in logs again. Batches sized for average work often fail on unusual inputs.
- Only deployment fails: Follow the startup steps above; the invocation limit is not the issue.
The Bottom Line
Split the job only when the time is real CPU work, the work divides into independent items, and each batch can be retried safely. If the time is spent waiting, or one item alone exceeds the allowance, splitting will not fix the error.
Quick Recap
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.
