Limits

Warning

The following limits apply to both Workers Paid and Workers Free plans with the exception of Message Retention, which is non-configurable at 24 hours for the Workers Free plan.

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 KB is measured as 1000 bytes. Messages can include up to ~100 bytes of internal metadata that counts towards total message limits.

² 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.

³ 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.

⁴ Individual queues that reach this limit will receive a Storage Limit Exceeded error when calling send() or sendBatch() on the queue.

⁵ 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:

wrangler.jsonc

{
  // ...rest of your configuration...
  "limits": {
    "cpu_ms": 300000, // 300,000 milliseconds = 5 minutes
  },
  // ...rest of your configuration...
}

wrangler.toml

[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. When the client disconnects, tasks are canceled unless you call waitUntil() to extend execution by up to 30 seconds.
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.
Workflows (per step)	Unlimited	Each step can run for an unlimited wall time. Individual steps are subject to the configured CPU time limit.