Overview
Cloudflare Queues enables asynchronous message passing between Workers. Send messages to a queue and process them with consumer Workers at your own pace.Queue Management
Create a Queue
Create a new message queue:<name>- Queue name (required)--delivery-delay-secs- Message delivery delay (0-43200 seconds)--message-retention-period-secs- How long to retain messages- Free tier: 60-86400 seconds (1 min - 24 hours)
- Paid tier: 60-1209600 seconds (1 min - 14 days)
wrangler.json
List Queues
View all queues in your account:--page- Page number for pagination
Get Queue Info
Retrieve detailed information about a queue:- Queue ID and name
- Creation and modification dates
- Producer and consumer counts
- Settings (delivery delay, retention period)
Update Queue Settings
Modify queue configuration:Delete a Queue
Delete a queue and all its messages:Queue Operations
- Pause/Resume
- Purge
Consumer Management
Add Consumer
Attach a Worker as a consumer:<queue>- Queue name<script>- Consumer Worker name--batch-size <n>- Messages per batch (default: 10, max: 100)--max-retries <n>- Maximum retry attempts (default: 3)--max-wait-time-ms <ms>- Max wait for batch (default: 5000)--max-concurrency <n>- Concurrent consumer invocations--visibility-timeout-ms <ms>- Message visibility timeout (default: 30000)--retry-delay <seconds>- Delay before retry (default: 60)--dead-letter-queue <queue>- Queue for failed messages--env <environment>- Worker environment
wrangler.json
Update Consumer
Modify consumer settings:consumer add.
Remove Consumer
Detach a consumer from a queue:List Consumers
View all consumers for a queue:HTTP Pull Consumer
Create a pull-based consumer for external systems:Add HTTP Pull Consumer
--batch-size <n>- Messages per pull--visibility-timeout-ms <ms>- Message visibility timeout
Remove HTTP Pull Consumer
Event Subscriptions
Subscribe to R2 bucket events:Create Subscription
object-create- Object uploadedobject-delete- Object deleted
List Subscriptions
Update Subscription
Delete Subscription
Producer Worker
Send messages to a queue from a Worker:Consumer Worker
Process messages from a queue:Message API
Message Properties:id- Unique message IDtimestamp- When message was sentbody- Message content (any JSON-serializable data)attempts- Number of delivery attempts
ack()- Mark as successfully processedretry()- Retry delivery (up to max_retries)retryAll()- Retry entire batchackAll()- Acknowledge entire batch
messages- Array of messagesqueue- Queue nameretryAll()- Retry all messagesackAll()- Acknowledge all messages
Best Practices
Message Design
- Keep messages small and focused
- Use JSON for structured data
- Include metadata for debugging (timestamp, version)
- Design for idempotency
Consumer Configuration
- Set appropriate batch sizes (10-100)
- Configure retries based on use case
- Use dead letter queues for failed messages
- Set visibility timeout > processing time
Error Handling
- Implement proper error handling in consumers
- Use try-catch around message processing
- Log errors with message IDs
- Monitor dead letter queues
Performance
- Batch messages when sending
- Process messages concurrently when safe
- Use max_concurrency to control load
- Monitor queue depth and processing lag
Use Cases
Background Processing
Background Processing
Offload time-consuming tasks from request handlers:
- Image/video processing
- Report generation
- Data aggregation
- Email sending
Event-Driven Architecture
Event-Driven Architecture
React to events asynchronously:
- R2 object uploads (event subscriptions)
- User actions requiring follow-up
- System state changes
- Scheduled tasks
Load Leveling
Load Leveling
Smooth out traffic spikes:
- Queue requests during high load
- Process at controlled rate
- Prevent downstream overload
- Handle bursts gracefully
Fan-Out Processing
Fan-Out Processing
Distribute work across multiple consumers:
- Parallel data processing
- Multi-step workflows
- Microservice coordination
- Batch operations
Limits
- Message size: 128 KB
- Batch size: 100 messages
- Max retries: Configurable (default: 3)
- Retention: 1 minute - 14 days (depending on plan)
- Delivery delay: 0 - 12 hours
Related Commands
- Durable Objects - Stateful coordination
- R2 Storage - Event subscriptions
- D1 Database - Persistent storage