Products · Developer platform
Queues
Reliably send and receive messages without the egress fees
Pricing and limits
Pricing
As of Nov 3, 2026, from Cloudflare's docs, last updated there Oct 30, 2026. Licensed CC BY 4.0; navigation removed.
Cloudflare Queues charges for operations and for queues above the included amount on the Workers Paid plan.
- 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.
| Workers Free | Workers Paid | |
|---|---|---|
| Standard operations | 10,000 operations/day included | 1,000,000 operations/month included + $0.40/million operations |
| Queues per account | 10,000 | Unlimited, with a default limit of 10,000. First 10,000 included + $0.10 per additional queue per month. |
| Message retention | 24 hours (non-configurable) | 4 days default, configurable up to 14 days |
Refer to Queues limits for queue creation limits and how to request a limit increase.
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 operations charges, excluding charges for additional queues:
((Number of Messages * 3) - 1,000,000) / 1,000,000 * $0.40
Additionally:
- 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 Dead Letter Queue 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.
Examples
If an application writes, reads and deletes (consumes) one million messages a day (in a 30 day month), and each message is less than 64 KB in size, the estimated bill for the month would be:
| Total Usage | Free Usage | Billed Usage | Price | |
|---|---|---|---|---|
| Standard operations | 3 * 30 * 1,000,000 | 1,000,000 | 89,000,000 | $35.60 |
| (write, read, delete) | ||||
| TOTAL | $35.60 |
An application that writes, reads and deletes (consumes) 100 million ~127 KB messages (each message counts as two 64 KB chunks) per month would have an estimated bill resembling the following:
| Total Usage | Free Usage | Billed Usage | Price | |
|---|---|---|---|---|
| Standard operations | 2 * 3 * 100 * 1,000,000 | 1,000,000 | 599,000,000 | $239.60 |
| (2x ops for > 64KB messages) | ||||
| TOTAL | $239.60 |
Limits
As of Nov 3, 2026, from Cloudflare's docs, last updated there Oct 30, 2026. Licensed CC BY 4.0; navigation removed.
Caution
The following limits apply to both Workers Paid and Workers Free plans except for queue counts and Message Retention, which is non-configurable at 24 hours for the Workers Free plan.
| Feature | Limit |
|---|---|
| Queues | Workers Paid: Unlimited, with a default limit of 10,000 per account. Each queue above 10,000 costs $0.10 per month. Workers Free: 10,000 per account. |
| Message size | 128 KB 1 |
| Message retries | 100 |
| Maximum consumer batch size | 100 messages |
Maximum messages per sendBatch call |
100 (or 256KB in total) |
| Maximum Batch wait time | 60 seconds |
| Per-queue message throughput | 5,000 messages per second 2 |
| Message retention period 3 | Configurable up to 14 days. |
| Per-queue backlog size 4 | 25GB |
| Concurrent consumer invocations | 250 push-based only |
| Consumer duration (wall clock time) | 15 minutes 5 |
| Consumer CPU time | Configurable to 5 minutes |
visibilityTimeout (pull-based queues) |
12 hours |
delaySeconds (when sending or retrying) |
24 hours |
1 1 KB is measured as 1000 bytes. Messages can include up to ~100 bytes of internal metadata that counts towards total message limits.
2 Exceeding the maximum message throughput will cause the send() and sendBatch() methods to throw an exception with a Too Many Requests error until your producer falls below the limit.
3 Messages in a queue that reach the maximum message retention are deleted from the queue. Queues does not delete messages in the same queue that have not reached this limit.
4 Individual queues that reach this limit will receive a Storage Limit Exceeded error when calling send() or sendBatch() on the queue.
5 Refer to Workers limits.
Need a higher limit?
To request an adjustment to a limit, complete the Limit Increase Request Form ↗︎. If the limit can be increased, Cloudflare will contact you with next steps.
Increasing Queue Consumer Worker CPU Limits
Queue consumer Workers are Worker scripts, and share the same per invocation CPU limits as any Workers do. Note that CPU time is active processing time: not time spent waiting on network requests, storage calls, or other general I/O.
By default, the maximum CPU time per consumer Worker invocation is set to 30 seconds, but can be increased by setting limits.cpu_ms in your Wrangler configuration:
{
// ...rest of your configuration...
"limits": {
"cpu_ms": 300000, // 300,000 milliseconds = 5 minutes
},
// ...rest of your configuration...
}
[limits]
cpu_ms = 300_000
To learn more about CPU time and limits, review the Workers documentation.
Wall time limits by invocation type
Wall time (also called wall-clock time) is the total elapsed time from the start to end of an invocation, including time spent waiting on network requests, I/O, and other asynchronous operations. This is distinct from CPU time, which only measures time the CPU spends actively executing your code.
The following table summarizes the wall time limits for different types of Worker invocations across the developer platform:
| Invocation type | Wall time limit | Details |
|---|---|---|
| Incoming HTTP request | Unlimited | No hard limit while the client remains connected. Workers requests are subject to the grace period for runtime updates. A Worker that is still streaming a response body remains active. waitUntil() extends execution for up to 30 seconds after the response or disconnect. |
| Cron Triggers | 15 minutes | Scheduled Workers have a maximum wall time of 15 minutes per invocation. |
| Queue consumers | 15 minutes | Each consumer invocation has a maximum wall time of 15 minutes. |
| Durable Object alarm handlers | 15 minutes | Alarm handler invocations have a maximum wall time of 15 minutes. |
| Durable Objects (RPC / HTTP) | Unlimited | No hard limit while the caller stays connected to the Durable Object. Durable Objects remain active while a request, RPC call, response stream, WebSocket, or pending I/O is in flight. |
| Workflows (per step) | Unlimited | Each step can run for an unlimited wall time. Individual steps are subject to the configured CPU time limit. |
Timeline
October 2026
- Increased Errors for Durable Objects in the Eastern North America region Incident
Minor impact. Resolved Oct 28, 2026, 11:10 UTC.
- Increased Errors for Durable Objects in the Eastern North America region Incident
Minor impact. Resolved Oct 28, 2026, 03:28 UTC.
- Queues now supports EU, US, and FedRAMP jurisdictions
You can now create Cloudflare Queues with jurisdictional restrictions, ensuring that messages published to a queue are stored and processed only within a specific jurisdiction. This helps you comply with data residency requirements such as the GDPR ↗︎ or FedRAMP ↗︎. To create a jurisdiction-restricted queue with the Cloudflare CLI (cf), use the --jurisdiction flag: cf queues create --queue-name m…
September 2026
- Subscribe to Browser Run crawl events
Browser Run crawl jobs can publish lifecycle events to Cloudflare Queues. Subscribe to started, updated, and finished events to track progress or trigger downstream processing without polling. To create an account-level subscription, run the following command: npmyarnpnpm npx wrangler queues subscription create <QUEUE_NAME> --source browserRun --events crawl.started,crawl.updated,crawl.finished -…
July 2026
- Subscribe to Email Sending events with Queues
You can now subscribe to Email Sending events through Queues event subscriptions and receive outbound transactional email lifecycle events on a queue. Each subscription is scoped to one sending domain — either the zone apex, such as example.com, or a verified sending subdomain, such as send.example.com. Six event types are published: message.delivered, message.deferred, message.bounced, message.f…
June 2026
- Billable usage and budget alerts now in product sidebars
Pay-as-you-go customers can now view billable usage and create budget alerts directly from the product overview pages for Workers & Pages, D1, R2, Workers KV, Queues, Vectorize, Durable Objects, and Containers. A new sidebar widget shows current-period spend and the billing cycle date range, alongside a button to create a budget alert. The widget pulls from the same data as the Billable Usage das…
May 2026
- Event subscriptions for Artifacts lifecycle events
You can now receive event notifications for Artifacts repository changes and consume them from a Worker to build commit-driven automation. This allows you to: Run custom workflows when a repository is created or imported Kick off a build and deploy a change when an agent pushes to a repo Trigger a review agent on every push Available events include: Account-level events (artifacts source) — repo.…
April 2026
- Realtime backlog metrics now available for Queues
Queues, Cloudflare's managed message queue, now exposes realtime backlog metrics via the dashboard, REST API, and JavaScript API. Three new fields are available: backlog_count — the number of unacknowledged messages in the queue backlog_bytes — the total size of those messages in bytes oldest_message_timestamp_ms — the timestamp of the oldest unacknowledged message The following endpoints also no…
February 2026
- Cloudflare Queues now available on Workers Free plan
Cloudflare Queues is now part of the Workers free plan, offering guaranteed message delivery across up to 10,000 queues to either Cloudflare Workers or HTTP pull consumers. Every Cloudflare account now includes 10,000 operations per day across reads, writes, and deletes. For more details on how each operation is defined, refer to Queues pricing ↗︎. All features of the existing Queues functionalit…
January 2026
- Get notified when your Workers builds succeed or fail
You can now receive notifications when your Workers' builds start, succeed, fail, or get cancelled using Event Subscriptions. Workers Builds publishes events to a Queue that your Worker can read messages from, and then send notifications wherever you need — Slack, Discord, email, or any webhook endpoint. You can deploy this Worker ↗︎ to your own Cloudflare account to send build notifications to S…
August 2025
- Subscribe to events from Cloudflare services with Queues
You can now subscribe to events from other Cloudflare services (for example, Workers KV, Workers AI, Workers) and consume those events via Queues, allowing you to build custom workflows, integrations, and logic in response to account activity. Event subscriptions allow you to receive messages when events occur across your Cloudflare account. Cloudflare products can publish structured events to a…
May 2025
- Publish messages to Queues directly via HTTP
You can now publish messages to Cloudflare Queues directly via HTTP from any service or programming language that supports sending HTTP requests. Previously, publishing to queues was only possible from within Cloudflare Workers. You can already consume from queues via Workers or HTTP pull consumers, and now publishing is just as flexible. Publishing via HTTP requires a Cloudflare API token with Q…
April 2025
- Increased limits for Queues pull consumers
Queues pull consumers can now pull and acknowledge up to 5,000 messages / second per queue. Previously, pull consumers were rate limited to 1,200 requests / 5 minutes, aggregated across all queues. Pull consumers allow you to consume messages over HTTP from any environment—including outside of Cloudflare Workers. They’re also useful when you need fine-grained control over how quickly messages are…
March 2025
- New Pause & Purge APIs for Queues
Queues now supports the ability to pause message delivery and/or purge (delete) messages on a queue. These operations can be useful when: Your consumer has a bug or downtime, and you want to temporarily stop messages from being processed while you fix the bug You have pushed invalid messages to a queue due to a code change during development, and you want to clean up the backlog Your queue has a…
February 2025
- Customize queue message retention periods
You can now customize a queue's message retention period, from a minimum of 60 seconds to a maximum of 14 days. Previously, it was fixed to the default of 4 days. You can customize the retention period on the settings page for your queue, or using Wrangler: Update message retention periodbash$ wrangler queues update my-queue --message-retention-period-secs 600 This feature is available on all new…