The Workers Paid plan includes Workers, Pages Functions, Workers KV, and Durable Objects usage for a minimum charge of $5 USD per month for an account. The plan includes increased initial usage allotments, with clear charges for usage that exceeds the base plan.
All included usage is on a monthly basis.
Workers are available under two Usage Models: Bundled and Unbound. Usage Models are settings on your Workers that specify how you are billed for usage, as well as the upper for how many milliseconds of CPU time your Worker can use per invocation. Worker size, number of Workers, and available memory are not affected by plan type. Refer to .
- Inbound requests to your Worker. to external services are not billed on a unit basis, but do impact the duration (wall-clock time) of your Worker.
Bundled Usage Model
The Bundled Usage Model is billed exclusively based on the number of incoming requests to your Worker, and has a limit of 50 ms of CPU time per invocation.
|Bundled||10 million included per month|
+$0.50 per additional million
|no charge for duration||50 milliseconds CPU time per invocation|
A Worker that serves 100 million requests per month would have the following estimated costs:
|Workers Paid Plan||$5|
|Requests||$45||(100,000,000 requests - 10,000,000 included requests) / 1,000,000 * $0.50|
Unbound Usage Model
The Unbound Usage Model is billed based on the number of incoming requests to your Worker, and the duration (wall-clock time) of each invocation, measured in gigabyte seconds (GB-s).
Cloudflare will bill for duration charges based on the higher of your wall time or CPU time, with a multiple of 8 applied to the CPU time to account for the processing power allotted to your Worker. Cloudflare will not bill for wall time duration charges beyond the execution given.
Duration billing will charge for the 128 MB of memory allocated to your Worker, regardless of actual usage. If your account has significant traffic to a single Worker, multiple instances of that Worker may run in the same isolate on the same physical machine and share the 128 MB of memory. These Workers are still billed as if they were separate instances, with each being charged as if it had its own 128 MB of memory.
Consider a Worker that serves 100 million requests per month, with an average duration (wall-clock time) of 200 milliseconds per request. This translates to the following duration (wall-clock time) metrics:
- 0.2 seconds per request (200 milliseconds / 1000)
- 0.025 gigabyte seconds (GB-s) per request (0.2 seconds * 128 MB / 1024 MB)
- 2,500,000 gigabyte seconds (GB-s) per month (0.025 GB-s per request * 100,000,000 requests)
Resulting in the following estimated costs:
|Workers Paid Plan||$5.00|
|Requests||$14.85||(100,000,000 requests - 1,000,000 included requests) / 1,000,000 * $0.15|
|Duration||$26.25||(2,500,000 GB-s per month - 400,000 included GB-s) / 1,000,000 * $12.50|
Standard Usage Model
A Worker that serves 100 million requests per month, and uses an average of 7 milliseconds (ms) of CPU time per request, would have the following estimated costs:
|Requests||$27.00||(100,000,000 requests - 10,000,000 included requests) / 1,000,000 * $0.30|
|CPU time||$13.40||(7 ms of CPU time per request * 100,000,000 requests - 30,000,000 included CPU ms) / 1,000,000 * $0.02|
How to switch Usage Models
When an account is first upgraded to the Paid plan, the Unbound plan is used as the default Usage Model. To change your default account-wide Usage Model:
- Log in to the and select your account.
- In Account Home, select Workers & Pages.
- Find Default Usage Model on the right-side menu > Change.
Existing Workers will not be impacted when changing the default Usage Model. You may change the Usage Model for individual Workers without affecting your account-wide default.
To change the Usage Model for individual Workers:
- Log in to the and select your account.
- In Account Home, select Workers & Pages.
- In Overview, select your Worker > Settings > Usage Model.
Workers Trace Events Logpush
Workers Logpush is only available on the Workers Paid plan.
|Requests 1||10 million / month, +$0.05/million|
1 Workers Logpush charges for request logs that reach your end destination after applying filtering or sampling.
|Free plan1||Paid plan|
|Read requests||100,000 / day||10 million/month, + $0.50/million|
|Write requests||1,000 / day||1 million/month, + $5.00/million|
|Delete requests||1,000 / day||1 million/month, + $5.00/million|
|List requests||1,000 / day||1 million/month, + $5.00/million|
|Stored data||1 GB||1 GB, + $0.50/ GB-month|
- The Workers Free plan includes limited Workers KV usage. All limits reset daily at 00:00 UTC. If you exceed any one of these limits, further operations of that type will fail with an error.
Cloudflare Queues charges for the total number of operations against each of your queues during a given month.
- An operation is counted for each 64 KB of data that is written, read, or deleted.
- Messages larger than 64 KB are charged as if they were multiple messages: for example, a 65 KB message and a 127 KB message would both incur two operation charges when written, read, or deleted.
- A KB is defined as 1,000 bytes, and each message includes approximately 100 bytes of internal metadata.
- Operations are per message, not per batch. A batch of 10 messages (the default batch size), if processed, would incur 10x write, 10x read, and 10x delete operations: one for each message in the batch.
- There are no data transfer (egress) or throughput (bandwidth) charges.
|Standard operations||1,000,000 operations / month||$0.40 / million operations|
In most cases, it takes 3 operations to deliver a message: 1 write, 1 read, and 1 delete. Therefore, you can use the following formula to estimate your monthly bill:
((Number of Messages * 3) - 1,000,000) / 1,000,000 * $0.40
- Each retry incurs a read operation. A batch of 10 messages that is retried would incur 10 operations for each retry.
- Messages that reach the maximum retries and that are written to a incur a write operation for each 64 KB chunk. A message that was retried 3 times (the default), fails delivery on the fourth time and is written to a Dead Letter Queue would incur five (5) read operations.
- Messages that are written to a queue, but that reach the maximum persistence duration (or “expire”) before they are read, incur only a write and delete operation per 64 KB chunk.
|Rows read||5 million / day||First 25 billion / month included + $0.001 / million rows|
|Rows written||100,000 / day||First 50 million / month included + $1.00 / million rows|
|Storage (per GB stored)||5 GB (total)||First 5 GB included + $0.75 / GB-mo|
- Rows read measure how many rows a query reads (scans), regardless of the size of each row. For example, if you have a table with 5000 rows and run a
SELECT * FROM tableas a full table scan, this would count as 5,000 rows read. A query that filters on an may return fewer rows to your Worker, but is still required to read (scan) more rows to determine which subset to return.
- Rows written measure how many rows were written to D1 database. A query that
INSERT10 rows into a
userstable would count as 10 rows written.
- Row size or the number of columns in a row does not impact how rows are counted. A row that is 1 KB and a row that is 100 KB both count as one row.
- Defining on your table(s) reduces the number of rows read by a query when filtering on that indexed field. For example, if the
userstable has an index on a timestamp column
created_at, the query
SELECT * FROM users WHERE created_at > ?1would only need to read a subset of the table.
- Indexes will add an additional written row when writes include the indexed column, as there are two rows written: one to the table itself, and one to the index. The performance benefit of an index and reduction in rows read will, in nearly all cases, offset this additional write.
- Storage is based on gigabytes stored per month, and is based on the sum of all databases in your account. Tables and indexes both count towards storage consumed.
- Free limits reset daily at 00:00 UTC. Monthly included limits reset based on your monthly subscription renewal date, which is determined by the day you first subscribed.
- There are no data transfer (egress) or throughput (bandwidth) charges for data accessed from D1.
|Requests1||1 million, + $0.15/million|
|Duration2||400,000 GB-s, + $12.50/million GB-s3,4|
3 Duration is billed in wall-clock time as long as the Object is active, but is shared across all requests active on an Object at once. Once your Object finishes responding to all requests, it will stop incurring duration charges. Calling
accept() on a WebSocket in an Object will incur duration charges for the entire time the WebSocket is connected. If you prefer, use instead, which will stop incurring duration charges once all event handlers finish running.
4 Duration billing charges for the 128 MB of memory your Durable Object is allocated, regardless of actual usage. If your account creates many instances of a single Durable Object class, Durable Objects may run in the same isolate on the same physical machine and share the 128 MB of memory. These Durable Objects are still billed as if they are allocated a full 128 MB of memory.
Durable Objects Transactional Storage API
Durable Objects do not have to use the Transactional Storage API, but if your code does call methods on
state.storage, it will incur the following additional charges:
|Read request units1,2||1 million, + $0.20/million|
|Write request units3||1 million, + $1.00/million|
|Delete requests4||1 million, + $1.00/million|
|Stored data5||1 GB, + $0.20/ GB-month|
1 A request unit is defined as 4 KB of data read or written. A request that writes or reads more than 4 KB will consume multiple units, for example, a 9 KB write will consume 3 write request units.
2 List operations are billed by read request units, based on the amount of data examined. For example, a list request that returns a combined 80 KB of keys and values will be billed 20 read request units. A list request that does not return anything is billed for 1 read request unit.
3 Each alarm write is billed as a single write request unit.
4 Delete requests are unmetered. For example, deleting a 100 KB value will be charged one delete request.
5 Durable Objects will be billed for stored data until the data is removed. Once the data is removed, the object will be cleaned up automatically by the system.
Vectorize is currently only available on the Workers paid plan.
1 Vectorize will be available to developers on the Workers Free plan in the future.
Calculating vector dimensions
To calculate your potential usage, calculate the sum of your stored + queried vectors, multiply by the dimension size, and multiply by the unit price (divided by 1 million). The formula is defined as
(stored vectors + queried vectors) * dimensions * ($0.040 / 1000000)
- For example, inserting 10,000 vectors of 768 dimensions each, and querying those 1,000 times per day (30,000 times per month) would be calculated as
(30000 * 768) = 23,040,000queried dimensions and
(10000 * 768) = 7,680,000stored dimensions (within the included monthly allocation)
- Separately, and excluding the included monthly allocation, this would be calculated as
(30,000+10,000) * 768 * ($0.040 / 1,000,000)and sum to $1.23 per month.
Service bindings cost the same as any normal Worker. Each invocation is charged as if it is a request from the Internet with one important difference. You will be charged a single billable duration across all Workers triggered by a single incoming request.
Workers Paid plan is separate from any other Cloudflare plan (Free, Professional, Business) you may have. If you are an Enterprise customer, reach out to your account team to confirm pricing details.
Only requests that hit a Worker will count against your limits and your bill. Since Cloudflare Workers runs before the Cloudflare cache, the caching of a request still incurs costs. Refer to to review definitions and behavior after a limit is hit.