Cloudflare Workers Paid Plan: Free vs Paid and When to Upgrade

What the Cloudflare Workers Paid Plan Costs and Includes

Should you stay on Free or pay for Cloudflare Workers? The Paid plan has a low monthly base price and includes a request and CPU-time allowance well beyond what Free offers, with any usage beyond that billed incrementally per resource. For most small APIs and background jobs, that base fee is all you'll ever pay.

That base price unlocks the Standard usage model with far higher included allotments than Free, a default CPU-time limit per invocation that can be raised well beyond what Free allows, and access to platform products that are limited or unavailable on Free, like Durable Objects, longer Queues retention, and expanded Workers Logs. The official Workers pricing page lists per-unit overage rates for additional requests and additional CPU time, and confirms there are no data transfer or throughput charges for Workers themselves.

For most small APIs and background jobs you stay inside the included bundle and pay only the base fee. Once traffic, compute per request, or dependent services grow, you pay only for the dimension you exceed rather than moving to a higher tier, which is why predicting CPU time and request volume matters more than the base fee itself.

The base fee is only part of the picture. The real decision comes down to what each plan actually includes, side by side.

Cloudflare Workers Free vs Paid: Full Limits Comparison

The Cloudflare Workers Free plan caps daily requests and limits CPU time per invocation to a narrow window, while the Paid plan raises the request allowance to a monthly pool, expands the CPU-time budget per invocation substantially, and adds a monthly CPU-time pool on top.

The common mistake is treating that difference as just a higher request quota. With the raw allotments side by side, the next question is what those numbers actually cost once real traffic hits them. In practice the Free plan also removes entire product surfaces and enforces much lower per-invocation budgets that break real workloads long before the request counter does.

Paid unlocks capabilities that do not exist on Free at all. Durable Objects with the key-value storage backend is only available on the Workers Paid plan, while Free is limited to SQLite-backed objects. Workers for Platforms style scale, higher Cron Trigger counts, larger Queues retention, and Logpush also require Paid.

The practical differences matter most in four places:

• CPU time: Free limits CPU time per invocation to a narrow window; Paid raises that per-invocation ceiling considerably and adds its own monthly pool of included CPU time. See the Workers limits documentation for the current figures.
• State: KV read and write allowances move from a daily cap on Free to a monthly pool on Paid, as detailed on the pricing page. D1 follows the same pattern, moving from a daily row-read cap on Free to a monthly pool on Paid.
• Orchestration: Queues moves from a daily operations cap on Free to a monthly pool on Paid, and retention extends from a fixed, non-configurable window on Free to a longer, configurable window on Paid.
• Observability: Workers Logs moves from a daily write cap with short retention on Free to a larger monthly write allowance with longer retention on Paid.

If your design uses Durable Objects, D1 at scale, Queues, or R2 beyond Free's small allocation for storage and operations, the workflow determines the stack. You are on Paid for capability, not just volume.

Estimating Your Real Monthly Bill on the Paid Plan

The Paid plan bill starts at its base monthly fee, which includes a monthly allotment of requests and CPU time, with anything beyond that billed per unit at the rates published on the pricing page. That base covers the Standard usage model with no egress fees, and every other product is metered separately against its own included allotment.

Once you can estimate the bill, the real question becomes whether you need to be on this plan at all right now.

All dimensions on the Paid plan pricing page stack. Requests and CPU time are the two meters every Worker hits. KV, D1, Queues, Logs and other products add their own overage lines on top of the base subscription, using the rates listed in Cloudflare's own documentation.

How the math works in practice

Cloudflare documents the formula directly on its pricing page, with worked examples rather than hypotheticals:

Low-traffic API that stays inside included use — a project with a modest request volume at a few milliseconds of average CPU time, a few hundred thousand KV reads, and no heavy writes stays under both the request and CPU allotments, so it pays only the base fee. The pricing page shows the same outcome for a project where most traffic is static assets: the base fee covers it entirely, since static asset requests are free and unlimited.

Mid-size SaaS backend — Cloudflare's own worked example on the pricing page walks through a high-volume workload at single-digit-millisecond average CPU time, where the included request and CPU allotments cover most of the load and the overage for what's left adds a modest amount on top of the subscription line.

High-request-volume pipeline — a workload at the same average CPU time but roughly an order of magnitude more requests pushes both the request and CPU overage meters harder, producing a total documented directly on the pricing page. Adding cache in front of that workload at a high hit rate drops the CPU-driven portion sharply, since cache hits still count as requests but do not burn CPU.

In real builds, request cost rarely drives the bill. CPU time does if code is inefficient, loops on JSON parsing, or fans out without streaming. Smart Placement or repeated KV / D1 calls inside a hot path can inflate CPU time per invocation quickly. KV writes, D1 writes and Queue operations are the other spikes to model. Cloudflare's pricing page publishes the exact included allotments and per-unit overage rates for each.

KV writes and D1 writes cost meaningfully more per unit than KV reads or D1 reads, so a write-heavy pipeline blows past the included allocation much faster than a read-heavy one.

Cost estimates only matter once you know which limits you're actually bumping into, and that's usually where teams decide to upgrade.

Signs You've Outgrown the Cloudflare Workers Free Plan

You've outgrown the Cloudflare Workers Free plan when your Worker starts returning Error 1027 after hitting the daily request ceiling, or throws Error 1102 because one invocation needs more CPU time than Free allows. Both are hard stops on Free that only reset at midnight UTC.

Free does not charge overage. It fails closed. Paid removes the daily cap and lets you raise limits and pay for what you use. That distinction defines which signs are hard blockers versus soft scaling issues.

Check these triggers against your dashboard:

• You hit the daily request ceiling. Free caps requests per day per account. The dashboard shows Error 1027 and, depending on your route mode, either bypasses the Worker or serves an error page. This is a hard blocker — you need Paid, where requests draw from a much larger monthly pool and are billed incrementally beyond it.
• You exceed CPU time per invocation. Free's per-invocation CPU-time budget is narrow; Paid's default ceiling is far higher and can be raised further. If your code does auth, parsing, or image processing that regularly exceeds Free's limit, Free will terminate it. Check Metrics > Errors > Exceeded CPU Time Limits. Hard blocker on Free, configurable on Paid. See CPU time limits.
• You need more Cron Triggers than Free allows per account. Paid raises that ceiling considerably. If you need hourly collectors, nightly cleanups, and a few more schedules, you hit Free's limit quickly. Hard blocker.
• You need Durable Objects with key-value storage. Free can only create SQLite-backed Durable Objects. The legacy key-value storage backend is Paid-only. If your design relies on transaction(), alarms with heavy state, or you see docs listing key-value backend as Paid, that's a hard blocker. See the pricing breakdown.
• You exceed Free's subrequest or per-account Worker limits. Paid allows far more subrequests per invocation and far more Workers per account than Free. This shows up when you fan out to many APIs, R2, or D1 calls. Hard blocker on Free.
• You need logs past Free's retention window or Logpush. Free's log retention is short and its daily write volume is capped. Paid extends retention, raises the write allowance to a monthly pool, and unlocks Workers Logpush, which is Paid-only. If you are debugging incidents from last week or need to ship logs to your own storage, Free cannot cover it. Hard blocker for Logpush, soft for retention.
• You need production controls like more concurrent builds or longer queue retention. Paid extends queue retention well beyond Free's fixed one-day window and removes many Free throttles. If you are triaging missed queue messages or build limits, that's the signal to upgrade.

Common Billing Surprises After Upgrading to the Paid Plan

Cloudflare Workers Paid plan overages come from CPU time, Durable Object duration, and KV/D1 writes, not bandwidth or egress. Avoiding billing surprises is part of a bigger pattern: Workers pricing decisions are really infrastructure architecture decisions, and the workflow determines the stack, not the other way around.

CPU time burns quietly. Paid plan CPU is billed on active computation, so recursive service bindings, heavy JSON parsing, or crypto in a hot path that pushes average CPU time up sharply per request can add a large amount of billed CPU time over a month. The overage is small per unit but scales fast once you exceed the included allotment.

KV and D1 writes from logging. Writing a log line, cache entry, or analytics event to KV on every request hits the write path: KV charges per unit beyond its included quota, and D1 counts every inserted row as a row written. A cache that "logs to KV for debugging" can generate a large number of writes without changing request counts.

Durable Object duration while idle. Durable Objects are billed for duration in GB-seconds while active or idle in memory and not eligible for hibernation by default. Calling accept() on a WebSocket keeps the object active for the entire connection unless you use the Hibernation API. That means a large number of concurrent chat sockets can accrue duration continuously, not just on messages.

Egress is not the culprit. Workers, Queues, D1, and R2 all state there are no additional charges for data transfer (egress) or throughput (bandwidth) on the Workers platform. If you come from other clouds, that line is worth confirming once and then ignoring, since your cost levers are compute and state operations.

Set up monitoring manually. Use the billable usage dashboard to see daily cost breakdowns, and create budget alerts under Notifications > Add > Billable Usage. Cloudflare calculates projected spend daily and fires once per cycle when you cross a threshold you define.

Cloudflare's billing alerts are not on by default — teams that skip adding a Billable Usage notification in the dashboard are the ones who get surprised by a month-end invoice.

Fill this in during upgrade week:

Making the Paid Plan Decision Part of Your Infrastructure Plan

Cloudflare priced its Workers Paid plan to remove the hard Free-tier stops that block production workloads and to unlock Durable Objects and other paid-only services, at a base monthly price listed on the pricing page.

All of this (limits, costs, triggers, and gotchas) ultimately feeds one practical decision. If your Worker runs on a schedule, holds state, serves customer traffic under a custom domain, or needs more than a day of logs, you already need Paid. The rule of thumb teams use in practice is straightforward: prototype on Free, ship on Paid.

Budget for growth with two habits:

1. Start on Paid on day one for anything customer-facing. The base fee is lower risk than debugging a wall at 3am mid-launch.
2. Track the two meters that actually move your bill, requests and CPU time, and project from real traces, not estimates. Design for cache hits, batched writes, and hibernation-friendly objects before you optimize unit costs. Start with the work that needs doing, then size the plan to it.

For teams where Workers is not the product itself but one component inside a larger automation system (content pipelines, document processing, or e-learning delivery) the plan decision is usually made while mapping the entire architecture rather than in isolation. That is where a workflow-first infrastructure approach, as practiced by Hesham Mashhour - AI Content Systems, factors in, because the goal is ownership and long-term maintainability, not just the monthly line item.

If you are shipping, move to Paid early, monitor early, and keep people in control of the system that bills.

Sources (2)

1. Pricing
2. Usage-based billing