loke.dev
Static asset files and dynamic code requests split into separate counters before passing through a small edge compute meter.

Cloudflare Workers Free or Paid? Count Invocations and CPU

Estimate Cloudflare Workers Free and Paid from code invocations, static asset routing, peak daily traffic, CPU time, platform limits, and separate product usage.

Published By Loke9 min read

Cloudflare Workers pricing is simple after you separate three numbers: requests that actually invoke code, CPU milliseconds used by those invocations, and product usage outside the Worker runtime.

Commercial note: links through loke.dev/go are measured as outbound clicks. The Cloudflare and DigitalOcean links in this guide are currently direct and earn no commission.

Use the Cloudflare Workers Free vs Paid calculator to model dynamic requests, static asset routing, peak days, and CPU time. It stores no input.

The short answer

Use Workers Free while the peak day stays below its daily request allowance, every request class fits the Free CPU limit, and the remaining platform limits fit the project. Move to Paid when the application needs more traffic, CPU, subrequests, script capacity, assets, cron triggers, or another paid-only capability.

Do not estimate from page views alone. A single page can load many free static assets and make one billed API call, or it can invoke server-side code for the document and several data requests. The routing configuration decides which traffic reaches the Worker.

Current Workers request and CPU prices

On 24 July 2026, Cloudflare’s Workers pricing documentation listed a $5 USD monthly minimum for Workers Paid. It included 10 million requests and 30 million CPU milliseconds per month.

The same page listed additional requests at $0.30 per million and additional CPU at $0.02 per million CPU milliseconds. It said the base Workers plan has no separate data-transfer or throughput charge.

Paid monthly = $5 minimum + max(0, requests − 10,000,000) ÷ 1,000,000 × $0.30 + max(0, CPU ms − 30,000,000) ÷ 1,000,000 × $0.02

The calculator keeps the minimum, included amounts, and rates editable because pricing can change.

Reproduce the official $8 example

Cloudflare’s current pricing page gives an example with 15 million monthly Worker requests and 7ms average CPU per request.

  • Request overage: 5 million × $0.30 per million = $1.50
  • Total CPU: 15 million × 7ms = 105 million CPU ms
  • CPU overage: 75 million × $0.02 per million = $1.50
  • Total: $5 minimum + $1.50 requests + $1.50 CPU = $8

The calculator matches that result. Use it as a formula check, then replace both request and CPU values with the application’s measurements.

Static assets can be free

The static asset billing documentation says requests served as static assets are free and unlimited, while requests that invoke the Worker script use Workers pricing.

That distinction is useful for a static or hybrid application. HTML, CSS, JavaScript, images, and fonts can bypass the Worker when an asset matches, while API and server-rendered routes invoke code.

A project with 15 million requests can therefore cost the $5 Paid minimum when 12 million are free static asset requests and only 3 million invoke a small Worker. Count the two groups separately.

run_worker_first changes the bill

The same static asset documentation says matching paths configured with run_worker_first always invoke the Worker script. Those requests join the Worker request count and use CPU when the script runs.

Do not set run_worker_first globally just because one API prefix needs middleware. Use narrow positive patterns and negative patterns for assets that do not need code. Then verify the deployed routing behavior rather than trusting a local path list.

Cloudflare’s static asset binding guide documents that the default is to serve a matching asset without invoking the Worker first.

The calculator includes a percentage for static traffic routed through code. Set it to 100% to model a global Worker-first route and compare the result with the default asset-first path.

A Worker cache hit is still a Worker request

Caching an upstream response from inside Worker logic can reduce origin work and CPU on some requests. It does not make the original Worker invocation disappear.

The pricing documentation says requests served from Workers Cache are billed at the Worker request rate. CPU is billed when Worker code runs on a miss or bypass. Treat request charges and CPU savings as separate effects.

If a request can be served as a deployed static asset without invoking code, that is a different path from running a Worker to look up a cached response.

Free is a daily traffic decision

Cloudflare’s current Workers limits page lists 100,000 Worker requests per day on Free, resetting at midnight UTC. It lists no general requests-per-second limit.

A monthly average can hide the failure day. Divide monthly invocations by 30, then multiply by a measured peak-day factor. A project averaging 60,000 invocations can still cross 100,000 on a launch day.

The calculator uses a peak multiplier for this reason. Replace it with the largest recent daily total divided by the same period’s daily average.

The limits page says a Free Worker exceeding its daily allowance returns error 1027 unless route fail-open behavior bypasses the Worker. A security or authorization Worker should not rely on fail-open merely to keep the origin reachable.

Free also has a per-invocation CPU limit

The current limits page lists 10ms CPU per invocation on Free. Paid lists up to five minutes, with a 30-second default for HTTP requests.

CPU time is work performed by the runtime, not the full wall-clock duration spent waiting for a database or another HTTP service. An I/O-heavy request can take longer than its CPU use.

Do not test Free eligibility with only the average CPU across all routes. A 1ms asset-metadata route cannot offset a 14ms authentication route when the second route exceeds its own limit.

Enter the largest representative CPU value for each request class in the calculator. Then inspect the actual distribution and tail routes in Workers Analytics.

Password hashing, large JSON transforms, compression, image work, and expensive initialization deserve route-specific measurement. Upgrading the plan raises the limit but does not prove the operation belongs in the request path.

Count WebSockets and service bindings correctly

The pricing page says a WebSocket connection to a Worker is charged as the initial upgrade request. Messages routed through the Worker do not count as additional Worker requests. Durable Objects have their own WebSocket and duration billing rules.

For Workers Standard, a service binding call does not add another request fee. Cloudflare documents one initial request and the combined CPU time used across the connected Workers.

These rules make it possible to split code for ownership without automatically multiplying the request count. They do not remove the separate usage of Durable Objects, storage, queues, or other bound products.

Pages Functions use the same model

Cloudflare’s pricing page says Pages Functions are billed as Workers. A migration from Pages to Workers does not create a cheaper function category.

For a static Pages or Workers project, keep assets on the asset path. For server rendering, middleware, forms, and APIs, count the function invocations and CPU like any other Worker.

The $5 minimum is not the whole stack

The pricing page also lists separate usage for KV, D1, Durable Objects, R2, Queues, Workflows, Containers, and other products. Their included usage and rates must be added from the current table.

Included allocations are generally account-level monthly pools, not a fresh free allowance for every Worker. Inventory the account before assigning the entire included amount to one application.

A useful cost sheet has one row per product:

  • Worker requests and CPU
  • database reads, writes, and storage
  • object storage, operations, and retrieval class
  • stateful object requests, duration, and storage
  • queue messages and retries
  • logs, AI, images, browser work, or containers when used

Keep units visible. One million Worker requests, one million D1 rows, and one million queue operations are not interchangeable.

Check workload fit before comparing cents

Both current Workers plans list 128MB memory per isolate. Paid raises several limits, including subrequests, Worker size, environment variables, assets, cron triggers, and per-request CPU.

A process that needs a writable local disk, a continuously running server, more memory, a specific native runtime, or long background ownership may fit Containers or ordinary application hosting better than a standard Worker.

Do not force a server workload into Workers because the request formula looks cheap. Model the architecture that can actually run, recover, and be supported.

For a conventional server or managed runtime, compare the DigitalOcean Droplet and App Platform calculator.

Measure before changing plans

Use Workers Analytics for a recent normal period and a known peak. Capture:

  • daily Worker invocations by service and environment
  • static asset requests that bypass code
  • CPU median, upper percentiles, and the slowest request classes
  • errors 1027 and 1102, timeouts, and retries
  • usage from every bound Cloudflare product

Separate staging, preview, load-test, and production traffic when they share an account. The bill sees account usage even when the team thinks in projects.

Set a CPU limit in Wrangler or the dashboard that matches the intended work. Cloudflare’s pricing page recommends a maximum to reduce accidental runaway CPU and denial-of-wallet risk.

Sweden and invoice handling

Workers pricing is shown in USD. A Swedish business should use the real invoice and its own tax treatment rather than converting the public reference once and treating it as fixed SEK cost.

The base Workers request and CPU table does not add an egress line, but other products and external services can have their own transfer or regional charges. Check each product used by the architecture.

Choose Free when

  • the measured peak day remains below 100,000 Worker invocations
  • every request class fits the 10ms CPU limit
  • memory, subrequests, script size, assets, cron triggers, and other Free limits fit
  • a daily hard limit is acceptable for the workload

Choose Paid when

  • the application needs more daily traffic or CPU per request
  • higher platform limits or a paid-only product are required
  • the $5 minimum is acceptable even at low traffic
  • the team has measured separate product usage and set operational limits

Keep the estimate reviewable

Save the date, routing configuration, monthly and peak-day requests, CPU distribution, product usage, and price references beside the decision. Recheck after a framework or routing change because one middleware pattern can turn free assets into Worker invocations.

Run the current traffic through the Workers Free vs Paid calculator. Then

check the live Workers documentation before enabling a paid plan or relying on a Free limit.

Sources and further reading

  1. Workers Pricing · Cloudflare Developers
  2. Workers Limits · Cloudflare Developers
  3. Static Assets Billing and Limitations · Cloudflare Developers
  4. Static Assets Configuration and Bindings · Cloudflare Developers
  5. Static Assets Worker Script Routing · Cloudflare Developers
  6. New Workers Pricing: Never Pay to Wait on I/O Again · Cloudflare Blog
  7. Support for Routes in Workers with Static Assets · cloudflare/workers-sdk
  8. Static Assets with Workers RFC · cloudflare/workers-sdk