How does Cloudflare Workers pricing work?

Free vs Paid: core billing and limits

Every Cloudflare account starts on the Workers Free plan by default. It covers limited usage across Workers, Pages Functions, Workers KV, and Hyperdrive. The Free plan gives you 100,000 requests each day, resetting at 00:00 UTC. If your application spikes past that daily limit, Cloudflare returns Error 1027 to visitors unless you've configured that route to fail open and bypass the Worker.

The Workers Paid plan costs a minimum of $5 USD per month per account. That fee is completely separate from any zone plan (such as Pro or Business) that you might run on your domains. Upgrading unlocks Durable Objects, raises your subrequest ceiling, and moves your account to the Standard usage model.

On the Paid plan, your usage counters don't reset at the calendar month; they reset on your monthly subscription renewal date, based on the day you first subscribed. Memory limits are identical across both tiers: each Worker isolate gets up to 128 MB of memory, shared across whatever concurrent requests that isolate happens to be handling.

Requests: what gets billed and what is free

Cloudflare Workers bills only for inbound requests that reach your Worker. Because Workers runs before the Cloudflare edge cache, caching a request on the edge doesn't let you bypass Worker billing; the request still hit the Worker first, so it counts.

Here is how specific request types behave:

• Subrequests: Cloudflare doesn't bill you for subrequests made from inside your Worker. When your script calls fetch() to reach an external API, an origin database, or third-party webhooks, those outgoing calls incur zero request fees.
• Service Bindings: If Worker A calls Worker B using a Service Binding, Cloudflare treats the flow as one single request. You pay for the initial invocation of Worker A, plus the combined CPU time across both scripts.
• WebSockets: A WebSocket connection counts as a single billable request for the initial HTTP Upgrade handshake. Any subsequent WebSocket messages passing back and forth through the Worker do not count as requests.
• Static assets: Requests served directly as static assets are free and unlimited.
• Workers Caching: If you enable Workers Caching, requests served from that cache (including static files and worker-to-worker calls) cost the standard per-request rate. But there's an upside: CPU time is only billed on a cache miss or bypass, not when the response comes straight from cache.

CPU time vs wall-clock duration

The biggest surprise for developers migrating from AWS Lambda or Google Cloud Functions is how Cloudflare measures execution. Traditional serverless platforms bill for wall-clock time: if your function pauses for 800 ms waiting on an external database, you pay for those 800 ms of idle compute.

Cloudflare Workers does not bill for wall-clock duration on the Standard usage model. It bills strictly for CPU time, which measures only the milliseconds the CPU actively executes your JavaScript or WebAssembly. Time spent waiting on network I/O - like outbound fetch() requests, KV lookups, or Hyperdrive queries - consumes zero CPU time.

The average Worker consumes roughly 2.2 ms of CPU time per request. Workloads handling server-side rendering, JSON parsing, or cryptography usually take 10 to 20 ms.

For HTTP-triggered Workers, there's no hard duration limit as long as the client connection stays open. You can use ctx.waitUntil() to run background work after returning a response, which extends execution for up to 30 seconds after the response finishes or the client disconnects. Non-HTTP triggers behave differently: Cron Triggers, Durable Object Alarms, and Queue Consumers each have a strict 15-minute wall-clock duration limit. During runtime updates, old Worker processes get a 20-minute grace period to let active streams and WebSockets drain.

On the Paid plan, the default CPU limit is 30 seconds (30,000 ms). If you run heavy data processing, you can raise it up to 5 minutes (300,000 ms) in your Wrangler configuration:

{
  "limits": {
    "cpu_ms": 300000
  }
}

If your Worker runs over its CPU limit infrequently, the isolate has built-in flexibility and lets it slide. But if you exceed the limit consistently, Cloudflare terminates the isolate with Error 1102 (Worker exceeded resource limits). In your dashboard, this shows up under Metrics > Errors > Invocation Statuses as Exceeded CPU Time Limits, and logs record the outcome as exceededCpu.

Moving away from legacy usage models

If you set up your account years ago, some of your scripts might still sit on the legacy Bundled or Unbound pricing models. The Bundled model is particularly restrictive: it caps HTTP requests and Cron Triggers at 50 ms of CPU time, restricts you to 50 subrequests per invocation, and limits you to 50 Cache API calls per request.

Cloudflare recommends switching every Worker to the Standard usage model. Changing this setting only affects how billable usage is calculated; it has no technical impact on runtime behavior.

To change the usage model across your entire account:

1. Open the Cloudflare dashboard and go to Workers & Pages.
2. Find Usage Model in the right-side menu and select Change.

To change it for an individual Worker:

1. Go to Workers & Pages.
2. In Overview, select your Worker, then go to Settings > Usage Model.

Two monthly billing examples

To see how request counts and CPU overages interact on the Paid plan, look at two typical production workloads averaging 7 ms of CPU time per request.

Scenario A: 15 million requests per month

A mid-sized API handles 15 million requests in a billing cycle:

• Base subscription: $5.00
• Request charges: 15,000,000 requests minus the 10,000,000 included leaves 5,000,000 billable requests. At $0.30 per million, that is $1.50.
• CPU time charges: 15 million requests at 7 ms equals 105 million CPU ms. Subtracting the 30 million included leaves 75 million billable CPU ms. At $0.02 per million, that is $1.50.
• Total invoice: $8.00.

Scenario B: 100 million requests per month

A higher-volume service processes 100 million requests at the same 7 ms average:

• Base subscription: $5.00
• Request charges: 100,000,000 requests minus 10,000,000 included leaves 90,000,000 billable requests. At $0.30 per million, that is $27.00.
• CPU time charges: 100 million requests at 7 ms equals 700 million CPU ms. Subtracting the 30 million included leaves 670 million billable CPU ms. At $0.02 per million, that is $13.40.
• Total invoice: $45.40.

Keep in mind that supplementary tools add their own lines. For logging, Workers Logs gives you 20 million events included on Paid, then charges $0.60 per million after that. Workers Logpush costs $0.05 per million requests sent to your destination after filtering, with 10 million included. If you run Durable Objects, billing works differently: compute is billed on wall-clock duration at $12.50 per million GB-s (after 400,000 included GB-s) and rounded up to the next billable unit. You can check our detailed breakdown in How are Cloudflare Durable Objects billed? or review storage costs in How much does Cloudflare Workers KV cost?.

Watching Workers spend with Costbrake

Serverless code with zero egress fees feels safe until an upstream loop or rogue client hammers an uncapped endpoint. Cloudflare Workers doesn't offer native billing hard-stops out of the box, so tracking usage before month-end is critical.

Costbrake monitors what you spend across 23 cloud and AI providers, including Cloudflare, AWS, and OpenAI. It checks usage every 5 minutes on paid tiers (hourly on the Free plan) and evaluates live usage against list prices, syncing daily billed dollars about a day later when Cloudflare finalizes them.

If traffic surges, Costbrake alerts you when an hour costs more than 3x your 7-day baseline and at least $5 more than usual. You also get notifications at 50%, 80%, and 100% of your budget, alongside forecasts if your last 72 hours of traffic put you on track to bust your month-end target.

When something goes wrong, you can use Costbrake's manual brakes. Brakes are opt-in, never fire on their own, and let an admin confirm a safe circuit breaker:

• Cap CPU time per request: Forces a low CPU limit on an errant Worker so runaway invocations fail with Error 1102 instead of running up CPU overages.
• Detach custom domains and routes: Cuts incoming traffic from specific domains instantly.
• Turn off workers.dev and preview URLs: Blocks direct testing URLs without touching production routes.
• Pause queue delivery or cron triggers: Halts background jobs while leaving your deployed code intact.
• Block usage with a spend policy: Installs an account-level policy that blocks Workers or Durable Objects if spend hits $0.01 in the billing cycle.

You can link your account in minutes via agent setup or connect manually in the dashboard. Plans start at $0 for basic monitoring, while Pro runs $12 a month with brakes and Slack alerts. Learn more on Costbrake pricing or read our walkthrough on Can I put a spending limit on Cloudflare Workers, Durable Objects and R2?.