| Feature | Limit |
|---|---|
| Queues | 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.
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_000To learn more about CPU time and limits, review the Workers documentation.
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. 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. |