← All articles

Cloudflare Workers: the real 10ms CPU limit and how to live with it

04 February 20252 min read

Workers are powerful but strict. 10ms CPU per request — not wall time — disciplines how you write code.

Cloudflare Workers has one strict rule that changes everything: 10ms CPU per request on the standard plan. Not wall time — actual CPU only. Looks small, plenty if you know what you're doing.

What counts

Only active compute: parsing, JSON manipulation, crypto. fetch() calls to other services don't count (they are I/O wait). So a Worker that does "fetch backend → transform → return" has most time covered by I/O.

The three CPU killers

1. Catastrophic regex

A regex with exponential backtracking can burn 10ms on a 200-char input. When debugging shows "Worker time-out on one request", it is almost always regex. Use linear-time regex or, better, dedicated parsers.

2. JSON.parse on huge payloads

Parsing 500 KB JSON costs ~5-8ms. Add a transform and you're at the limit. Consider streaming JSON parse or upstream splitting.

3. Synchronous crypto

bcrypt/scrypt password hashing is heavy. For those, Workers Unbound (uncapped CPU, slightly costlier) or a dedicated service.

When to move to Workers Unbound

If your logic is truly CPU-bound (edge video encoding, edge ML, complex parsing), Workers Unbound has uncapped CPU billed on actual CPU time. Still cheaper than Lambda in most cases we've seen.

Observability

Cloudflare Analytics shows mean CPU time per Worker. If you see 8-9ms, time to refactor or promote to Unbound. Waiting for production timeouts is the worst path.