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

Quick answer (August 2026): Cloudflare Workers Paid starts at $5/month, which includes 10 million requests and 30 million CPU-milliseconds. Past that you pay $0.30 per additional million requests and $0.02 per additional million CPU-ms. The Free plan gives 100,000 requests/day with a 10 ms CPU cap per invocation. The number that decides your bill is CPU time, not how long the request takes, so a slow call that mostly waits on a database or an upstream API can still cost almost nothing. Three things most teardowns leave out: that $5 is an account-wide platform minimum that also covers Pages Functions, Workers KV, Hyperdrive and Durable Objects (each with its own separate allowance on top), Cloudflare does not bill subrequests your Worker makes, and there is no egress or bandwidth charge at all.

Updated August 22, 2026: every rate re-verified against Cloudflare's official Workers pricing page. All figures were unchanged. Added what the $5 platform minimum actually covers (with the Workers KV and Durable Objects allowances that sit on top of it), the subrequest billing rule, and the egress comparison against Lambda.

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 $5 is a platform minimum, not a Workers fee

This is the line item people get wrong in both directions, and it is worth being precise about because it changes what a realistic Cloudflare bill looks like.

That $5 a month is an account-wide minimum that covers Workers, Pages Functions, Workers KV, Hyperdrive and Durable Objects (Cloudflare Workers pricing, 2026). So you are not paying $5 for Workers and then another subscription for KV. One $5 minimum, one account.

What it does not mean is that those products are free once you have paid it. Each one carries its own included allowance and its own overage meters, stacked on top of the same $5:

The number to stare at is the KV write rate. Reads are $0.50 per million and writes are $5.00 per million, a ten-to-one gap, and deletes and list operations are priced as writes rather than as reads. A Worker that writes to KV on every request is on a meter ten times more expensive than one that reads on every request, and the included write allowance is a tenth of the read allowance. If you are using KV as a cache you are on the cheap side of that. If you are using it as a session store or a counter, you are not.

Durable Objects storage is priced separately again and varies by backend, SQLite or key-value, each with its own included amounts and rates. Check the current card for your backend before you model it.

Two costs that are simply not on the meter

Both of these are absences rather than line items, which is exactly why they get left out of comparisons, and both are worth real money.

Subrequests are not billed. Cloudflare does not charge for the subrequests a Worker makes (Cloudflare Workers pricing, 2026). If your Worker fans out to three internal services to assemble one response, that is one billed request, not four. Architectures that would be punished on a per-invocation meter elsewhere are free to be chatty here. The CPU those calls consume is still billed, but the calls themselves are not, and the time spent waiting on them is not either.

There is no egress or bandwidth charge. Cloudflare states plainly that there are no additional charges for data transfer out or throughput. For a Worker that serves any real volume of response bytes, this is often the difference that matters more than the compute line, and it is the same zero-egress posture that makes Cloudflare R2's pricing behave so differently from S3.

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.

The comparison that gets skipped is egress. Lambda's published rates are $0.20 per million requests and $0.0000166667 per GB-second, with a free tier of 1 million requests and 400,000 GB-seconds a month (AWS Lambda pricing, 2026). Those are the numbers everyone compares. But data transferred in and out of a Lambda from outside the function's region is billed at EC2 data transfer rates on top, while Workers charges nothing for transfer at all. Be fair about the caveat, because it is a real one: AWS makes data transfer free in the same region between Lambda and a specific list of services including S3, DynamoDB, SQS, SNS, Kinesis and EFS, so a Lambda that only talks to same-region AWS services pays no egress either. The gap opens when you serve bytes to the public internet or call across regions, which for a public HTTP endpoint is most of the time. 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.

Math check: take your monthly requests, multiply by your average CPU milliseconds per request, and compare the two numbers against 10 million and 30 million. Whichever ceiling you hit first is the only meter worth optimising. Then add your KV writes at $5.00 per million, because that is the line that quietly overtakes compute on a write-heavy Worker, and subtract the egress bill you would have paid somewhere else, because here it is zero.