Cloudflare Workers pricing surprises people in one specific way: the request line on the invoice is almost never the problem. At $0.30 per million requests, 100 million requests costs $30. The same 100 million requests at 20 ms of average CPU time costs another $34 in CPU billing, and if those Workers are pulling 40 TB of large objects out of R2 or a bucket behind them, the delivery economics stop being a Cloudflare question entirely. This piece gives you the 2026 rate card for Workers, Pages, and R2, three worked monthly cost models at 5M, 50M, and 500M requests, the limits that actually bite in production, and a threshold table for when to move bulk egress off the platform.
As of 2026 the structure is unchanged from the 2023 CPU-time billing switch, and that stability is worth noting — it means your 2024 cost models still hold if you rebuild them with current usage. What changed is the surrounding surface: Workers now routinely front Durable Objects, D1, Queues, Hyperdrive, and Workers AI, and each of those carries its own meter.
| Plan | Cost | Included | Overage |
|---|---|---|---|
| Free | $0 | 100,000 requests/day, 10 ms CPU per invocation | Hard stop, no overage |
| Paid | $5/month base | 10M requests + 30M CPU-ms | $0.30 per million requests; $0.02 per million CPU-ms |
| Enterprise | Negotiated | Committed volume, SLA, support | Discounted per-unit rates |
The billing model bills active CPU only. Awaiting a subrequest, a KV read, a D1 query, or an origin fetch is free wall-clock time. This is why an I/O-bound API gateway on Workers can serve 200 million requests for pocket change while a JSON-transforming, JWT-verifying, HTML-rewriting Worker at the same volume costs an order of magnitude more.
Assume Paid plan, $5 base, 10M requests and 30M CPU-ms included.
| Profile | Requests/mo | Avg CPU | Estimated monthly |
|---|---|---|---|
| Low: edge redirects, header rewrites | 5M | 1 ms | $5 (fully inside included tier) |
| Mid: auth + cache API + KV lookups | 50M | 5 ms | $5 + $12 requests + $4.40 CPU ≈ $21 |
| Mid, CPU-heavy: SSR + signature verify | 50M | 15 ms | $5 + $12 requests + $14.40 CPU ≈ $31 |
| High: API edge at scale | 500M | 8 ms | $5 + $147 requests + $79.40 CPU ≈ $231 |
The take-away from the mid rows: tripling CPU time only moved the bill from $21 to $31, because requests still dominate at moderate CPU. That inverts above roughly 15 ms average CPU, where the CPU line overtakes the request line. Instrument p50 and p95 CPU-ms separately — a p95 of 90 ms on 8 percent of traffic distorts the average more than most teams expect.
Pages remains the strongest free static-hosting economics available in 2026, and the reason is one line: static asset bandwidth is unmetered on every plan, including Free. What is metered is builds and concurrency.
| Plan | Cost | Builds & concurrency |
|---|---|---|
| Free | $0 | 500 builds/month, 1 concurrent, unlimited sites and static bandwidth |
| Pro | $20/month | 5,000 builds/month, 5 concurrent |
| Business | $200/month | 20,000 builds/month, 20 concurrent, advanced cache controls |
The trap in Cloudflare Pages pricing is Functions. Anything dynamic — middleware, SSR, edge API routes — bills under Workers rates. A Next.js app deployed to Pages with server components on every route is a Workers cost model wearing a Pages badge. Cloudflare's own direction in 2026 pushes new full-stack projects toward Workers with static assets rather than Pages Functions, so architect accordingly if you are starting fresh.
R2 as of 2026: $0.015 per GB-month for standard storage, $4.50 per million Class A operations (writes, lists), $0.36 per million Class B operations (reads), and $0 egress. Infrequent Access storage sits near $0.01 per GB-month with a per-GB retrieval charge. The free tier covers 10 GB storage, 1M Class A, and 10M Class B monthly.
Zero egress is real and it is the reason R2 wins against S3 for outbound-heavy object storage. But three costs replace it. First, operations: a chatty application doing per-object HEAD checks at 500M reads/month pays $180 in Class B alone. Second, R2 objects served through Workers still incur Workers request and CPU billing on the path. Third, R2 is storage, not a tuned delivery network — cache hit behaviour for large files served to a global audience is not the same as a purpose-built delivery tier.
Take a software vendor shipping installers and patch bundles. 40 TB egress, 8 TB stored, 60M reads. On R2: storage $120, Class B ops about $22, egress $0. Roughly $142 — genuinely hard to beat, and worth saying plainly. Add Workers in front for signed-URL validation at 60M requests and 6 ms CPU and you add about $22. Total near $164.
That is competitive. Where the math shifts is when you need delivery guarantees, per-region tuning, byte-range behaviour on multi-gigabyte objects, and a support path with an SLA. That is a different product category, and it is worth pricing separately rather than assuming one bill covers everything.
| Workload profile | Best fit | Why |
|---|---|---|
| I/O-bound API edge, under 10 ms CPU | Workers | Wait time unbilled; cold start effectively zero |
| Static site, SPA, docs | Pages / Workers static assets | Unmetered static bandwidth |
| CPU-heavy batch, over 30 s, over 128 MB | AWS Lambda / Fargate | Memory and duration headroom; Function URLs avoid API Gateway markup |
| Next.js-native product team | Vercel | Best framework integration; metered bandwidth and function invocations |
| Large-object egress above 25 TB/mo | Volume-priced CDN | Flat per-TB pricing beats per-request compute paths |
The architectural pattern worth adopting: treat Workers as your control plane and a dedicated delivery tier as your data plane. Signed URLs, entitlement checks, geo logic, and A/B routing run on Workers at single-digit CPU-ms. The multi-gigabyte payload — game build, VOD segment, model weights, installer — leaves via a delivery network priced per terabyte, not per request.
At 40 TB/month, BlazingCDN's volume pricing works out to $350 for the first 100 TB tier, or effectively $3.50 per TB, with entry pricing starting at $5 per TB ($0.005 per GB) on the 25 TB plan and scaling down to $2 per TB ($0.002 per GB) at 2 PB. It offers 100% uptime, flexible per-origin configuration, NVMe SSD edge storage, and roughly one-hour onboarding, with stability and fault tolerance comparable to Amazon CloudFront at a materially lower cost — which matters most for enterprises and large corporate clients running sustained multi-hundred-terabyte months.
Honest framing: in the high-volume, cost-at-scale CDN league — Bunny.net, CDN77, KeyCDN, Gcore, Medianova, and Fastly for streaming — several of these have genuine strengths. Bunny.net's per-region pricing is excellent for geographically concentrated traffic. Fastly's real-time purge and VCL flexibility remain best in class for complex streaming logic. BlazingCDN's argument is narrower and verifiable: predictable pay-as-you-go per-TB pricing with no request-count surprises, which is exactly the variable that makes Workers-plus-R2 bills unpredictable at scale. Run the per-TB math against your own traffic before deciding.
Both, on separate meters. As of 2026 the Paid plan bills $0.30 per million requests beyond 10M included, plus $0.02 per million CPU-milliseconds beyond 30M included. Time spent awaiting fetches, KV reads, or D1 queries is not billed, so I/O-bound Workers stay cheap regardless of wall-clock latency.
Around 15 ms average CPU per invocation. Below that, the $0.30 per million request charge dominates. Above it, CPU billing grows faster, so profiling p50 and p95 CPU-ms per route is the highest-value optimisation you can do on a Workers bill.
For static assets, yes — unmetered on Free, Pro, and Business as of 2026. Builds are the metered resource: 500 per month on Free, 5,000 on Pro, 20,000 on Business. Anything served by Pages Functions bills at Workers rates, so dynamic routes are not free.
For egress-heavy workloads, substantially. R2 charges $0.015 per GB-month storage and $0 egress, against S3's per-GB outbound charges. The costs that replace egress are Class A operations at $4.50 per million and Class B at $0.36 per million, so read-chatty applications should model operations carefully.
Roughly above 25 TB per month of large-object egress, once you also need SLA-backed delivery and per-origin tuning. Flat volume pricing in the $2 to $5 per TB range makes the comparison straightforward: multiply your monthly TB by both models and compare against the Workers request and CPU charges sitting on the same path.
The 128 MB memory ceiling, usually from buffering a request or response body instead of streaming it. Second most common is the 50-subrequest cap on fan-out patterns. Both surface under load rather than in staging, which is why synthetic load tests should exercise the largest payloads you expect, not the median.
Pull 30 days of Workers analytics and bucket CPU-ms by route, not by aggregate. Compute the request-charge and CPU-charge lines separately for each bucket and find the routes above 15 ms p50 — those are where refactoring pays. Then take your largest-object traffic in TB, multiply by $3.50 and by $5, and compare against what those same bytes currently cost you across Workers requests, CPU, and R2 operations combined. If the delta is more than a few hundred dollars a month, you have a data-plane problem, not a compute problem. What is your actual p95 CPU-ms, and do you know it per route?