Quick answer
Workers Free allows 10 ms of CPU time per HTTP request. Workers Paid defaults to 30 seconds and can be configured up to the current 30 seconds default; up to 5 minutes ceiling.
Verified Aug 22, 2026Official source
Current limits
| Constraint | Current value | Scope | Verified source |
|---|---|---|---|
| CPU time per HTTP requestCPU time excludes waiting on network requests and other I/O. | 10 ms | Workers Free | CloudflareAug 22, 2026 |
| Configurable CPU time per HTTP requestThe maximum is configurable with limits.cpu_ms; wall-clock duration is a separate concept. | 30 seconds default; up to 5 minutes | Workers Paid | CloudflareAug 22, 2026 |
Why does this limit matter?
CPU time counts active computation, not time waiting for fetches, KV reads, databases, or other I/O.
Buffering, parsing, image work, or large in-memory transformations can exhaust CPU even when wall time seems short.
What should you check?
- Inspect invocation CPU time in Workers logs or traces.
- Use local CPU profiling for expensive code paths.
- Check the configured limits.cpu_ms rather than assuming the paid maximum is active.
How to configure paid-plan CPU time
Cloudflare documents limits.cpu_ms in Wrangler configuration for paid Workers.
{
"limits": {
"cpu_ms": 300000
}
}This maximum is for eligible paid Workers. Choose the lowest safe ceiling and profile sustained overages.
Important caveats
- CPU and wall-clock duration are separate limits.
- Cron Triggers and other invocation types have different CPU and wall-time rules.
HyperObserve reports the documented platform constraint. Your application, SDK, gateway, provider, region, or account can impose a lower effective limit.
Related