Cloudflare Workers pricing in 2026: the real bill when you pay for CPU, not wall-clock time

Cloudflare Workers has a $5 minimum and a pricing model that trips up everyone who arrives from AWS. The trap is not the $5. It is assuming you are billed for how long your code runs. You are not. You are billed for how long the CPU actually works, which for most real workloads is a tiny fraction of the wall-clock time.

This is a worked teardown, not a feature tour. Real 2026 numbers, three real monthly bills, and the one breakpoint that decides whether requests or CPU is the meter that bankrupts you.

The model that changes everything: CPU time, not duration

On the Standard usage model, Cloudflare Workers bills the CPU time your Worker consumes, with no charge and no limit for duration (Cloudflare Workers pricing, 2026).

That distinction is the whole game. A Worker that calls a slow database, waits 400 milliseconds for the response, then does 3 milliseconds of work, is billed for roughly 3 milliseconds, not 403. The waiting is free. If you are coming from a platform that charges GB-seconds of wall-clock time, this inverts your intuition about what an expensive request is. On Workers, an idle wait costs nothing; only the processor cycles cost money.

The default CPU cap is 30 seconds per invocation, and you can raise it to 5 minutes (15 minutes for Cron Triggers and Queue consumers). Those are limits, not the thing you pay for.

The 2026 price sheet

Two meters, billed independently: requests and CPU milliseconds. Your bill is $5, plus whatever you spill over each meter. Source: Cloudflare Workers pricing, 2026.

The 3-millisecond breakpoint that decides your bill

Here is the arithmetic nobody publishes. The Paid plan includes 10 million requests and 30 million CPU-ms. Divide them: that is 3 CPU-ms of headroom per included request.

So the question that sets your bill is simple. What is your Worker's average CPU time per request?

• Under 3 ms average: requests are your binding meter. You will exhaust the 10 million request allowance before the CPU allowance. A JSON proxy, a redirect, a cache lookup, a simple auth check, all live here.
• Over 3 ms average: CPU is your binding meter. Image resizing, crypto, HTML rendering, heavy JSON transforms will burn the 30 million CPU-ms first.

Knowing which side you are on tells you which lever matters. If requests bind, batch or cache to cut request count. If CPU binds, optimize the hot path, because every millisecond shaved is $0.02 per million saved.

Three real monthly bills

Bill A: the hobby API proxy ($0)

• Free plan: $0
• 3 million requests a month (100,000 a day)
• Light logic, well under the 10 ms CPU cap per invocation
• Total: $0 per month

The Free plan is genuinely useful here. The only hard wall is the 10 ms CPU cap per invocation, which a proxy or router never hits. Cross 100,000 requests in a day and you need the Paid plan, but the cost of crossing is small, as the next bill shows.

Bill B: a small production Worker ($5)

• Paid plan: $5
• 8 million requests, averaging 3 ms CPU each, so 24 million CPU-ms
• Both under the included 10 million requests and 30 million CPU-ms
• Total: $5 per month

This is the honest floor for a real service. Notice how much fits inside the base fee: 8 million requests and 24 million CPU-ms and you still pay only the $5 minimum. The included allowances are generous enough that many production Workers never leave the base tier.

Bill C: a busy Worker ($24.40)

• Paid plan: $5
• 50 million requests, averaging 8 ms CPU each, so 400 million CPU-ms
• Requests overage: 40 million over, at $0.30 per million = $12.00
• CPU overage: 370 million CPU-ms over, at $0.02 per million = $7.40
• Total: about $24.40 per month

Fifty million requests for under $25 is the punchline. This is a compute-heavy Worker (8 ms average puts it on the CPU-bound side of the breakpoint), and it still lands cheap because idle time was never on the meter.

Why this is not AWS Lambda

The comparison people reach for is AWS Lambda , and the pricing philosophies are opposites. Lambda bills GB-seconds: memory multiplied by wall-clock duration (AWS Lambda pricing, 2026). A Lambda that waits 400 ms on a database pays for all 400 ms times its memory allocation. The same logic on Workers pays for the CPU only.

For latency-bound and IO-bound work, where the function spends most of its life waiting on a network call, Workers can be dramatically cheaper, because the wait is free. For pure CPU-bound batch crunching the gap narrows, since both platforms are then charging for the same processor work. Deno Deploy and Vercel sit in between with their own edge-function meters (Deno Deploy pricing, 2026). The rule of thumb: the more your code waits, the more the CPU-time model wins.

The gotcha to plan around

The one that surprises people is the 30-second default CPU cap per invocation. It is plenty for a request handler, but a long-running data job that does 45 seconds of actual computation will be cut off unless you raise the limit toward the 5-minute ceiling, or move it to a Cron Trigger or Queue consumer where the cap is 15 minutes. Design the heavy work to fit the CPU budget, or route it to the right invocation type before it becomes a production surprise.

Price the CPU first, the requests second, and remember that on Workers the clock on the wall is not the clock you pay for.