Cloudflare Queues solves the problem every serverless application eventually hits: a request arrives that triggers work the user should not have to wait for. Sending the confirmation email, resizing the upload, syncing the record to a third party. On a traditional server you hand that to a background worker process. On Workers there is no process to hand it to.
The usual workarounds are worse than they look. Doing the work inline makes the user wait for an email provider. Firing a request at another Worker and not awaiting it loses the job whenever the invocation ends first. Neither survives a provider outage.
What a queue buys you: durability and retries, not speed. The producer writes a message and returns immediately; a separate consumer Worker picks it up, and if the consumer fails the message goes back on the queue rather than into the void. That is the whole value. If your background job cannot tolerate being retried, a queue will not save you.
How the Pieces Fit
A queue has two ends and both are Workers.
The producer is any Worker with a queue binding. It calls send with a message body, and that call returns as soon as the message is durably stored. The user’s request finishes without waiting for the work.
The consumer is a Worker with a queue handler. Cloudflare invokes it with a batch of messages, and the handler acknowledges each one it processes successfully. Anything not acknowledged is redelivered.
The redelivery behaviour is the part worth designing around. A message can arrive more than once, which means your consumer must be idempotent. Charging a card in a queue consumer without an idempotency key is how you refund people. Sending an email twice is annoying; taking payment twice is a support incident.
A dead letter queue catches messages that fail repeatedly. Without one, a permanently broken message is retried until it exhausts its attempts and then vanishes. With one, it lands somewhere you can inspect it. Configure this before you need it.
What an Operation Actually Costs
The pricing model is unusual enough to trip people up, because you are not billed per message.
An operation is counted for each 64 KB of data written, read or deleted. A message under 64 KB delivered normally costs three operations: one write, one read, one delete. A 127 KB message costs two operations per action, so six in total for the same single delivery.
| Workers Free | Workers Paid | |
|---|---|---|
| Included | 10,000 operations per day | 1,000,000 operations per month |
| Beyond that | not available | $0.40 per million operations |
| Egress | none | none |
Retries change the arithmetic. Every redelivery is another read, and a write to the dead letter queue is another write. A consumer that fails a message five times before succeeding costs far more than three operations, which is a reason to fix a flaky consumer rather than raise its retry count.
Work the sums on your own traffic before assuming it is cheap. A million messages a month at three operations each is three million operations, which sits above the paid allowance and costs roughly eighty pence. That is genuinely cheap. Ten million messages a day is a different conversation.
The Limits That Decide Whether It Fits
From Cloudflare’s Queues limits documentation , verified August 2026.
| Limit | Value |
|---|---|
| Queues per account | 10,000 |
| Maximum message size | 128 KB |
| Messages per batch send | 100, or 256 KB total |
| Message retries | 100 |
| Retention period | configurable up to 14 days |
| Backlog per queue | 25 GB |
| Concurrent consumer invocations | 250, push-based only |
| Consumer wall-clock time | 15 minutes |
| Throughput per queue | 5,000 messages per second |
Two of these matter more than the rest. The 128 KB message ceiling means you do not put files in a queue. You put a pointer in the queue and the file in R2, which is the right shape anyway. The 25 GB backlog is what protects you from a silent disaster: if your consumer breaks on a Friday and nobody notices, the queue fills and then rejects new messages with a storage error rather than quietly discarding them.
The 5,000 messages per second per-queue throughput is generous, but it is per queue. A single hot queue is a bottleneck you can design away by sharding across several.
When Cloudflare Queues Is the Wrong Answer
When the work is genuinely synchronous. If the user needs the result on screen, queuing it just adds a round trip and a polling problem. Do it inline and make it fast.
When you need ordered, exactly-once processing. Queues gives you at-least-once delivery. Anything requiring strict ordering or exactly-once semantics needs coordination the queue does not provide, and on Cloudflare that usually means a Durable Object.
When it is a scheduled job, not a triggered one. Nightly cleanup does not need a queue. A cron trigger invoking a Worker directly is simpler and has fewer moving parts.
When the work exceeds 15 minutes. A consumer that runs longer than its wall-clock limit will be killed mid-job. Long multi-step processes want Cloudflare Workflows, which is built for durable execution across steps, rather than a queue consumer trying to hold state for a quarter of an hour.
Our guide to building a serverless API with Cloudflare Workers covers the request path that usually produces these jobs, and Cloudflare Workers versus AWS Lambda covers how the execution model differs from the SQS-and-Lambda pattern most teams arrive with.
Where to Start
Pick the one piece of work in your request handler that the user does not need to wait for, and move only that. Give it a dead letter queue on day one, make the consumer idempotent, and watch the backlog metric rather than assuming it is empty.
Mecanik designs and reviews edge architectures through our software development team, including the part where somebody asks whether the job needs a queue at all. Most systems need one or two, not one per feature.
Related reading: Cloudflare Hyperdrive: Postgres From the Edge , How to Build a Web App in 2026 - The UK Developer’s Guide , Cloudflare D1 - Build a Serverless SQL Database on the Edge and Cloudflare Workers AI - Run AI Models at the Edge in 2026 .
Frequently Asked Questions
How much does Cloudflare Queues cost? The Workers Free plan includes 10,000 operations per day and the Paid plan includes one million operations per month, with additional operations at $0.40 per million and no egress charges. An operation is counted for each 64 KB written, read or deleted, so a normal message under 64 KB costs three operations in total: one write, one read and one delete.
What counts as an operation in Cloudflare Queues? Each 64 KB of data written, read or deleted. A message smaller than 64 KB costs one operation per action, while a 127 KB message costs two per action. Retries add another read each time, and a write to the dead letter queue adds another write, so a flaky consumer costs considerably more than the base three operations per message.
What is the maximum message size in Cloudflare Queues? 128 KB per message, with batch sends limited to 100 messages or 256 KB in total. Because of that ceiling you store the payload in R2 or another object store and put only a pointer in the queue, which is the better design regardless of the limit.
Does Cloudflare Queues guarantee exactly-once delivery? No. Delivery is at-least-once, so a message can arrive more than once and your consumer must be idempotent. Charging a payment or issuing a credit inside a consumer without an idempotency key will eventually double up. Strict ordering or exactly-once semantics need a Durable Object instead.
When should I not use Cloudflare Queues? When the user is waiting for the result, when you need strict ordering or exactly-once processing, when the job is scheduled rather than triggered and a cron trigger would do, or when the work runs longer than the 15-minute consumer wall-clock limit. That last case is what Cloudflare Workflows exists for.
Comments