Skip to main content

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:
Options:
  • <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)
Examples:
Configuration: After creation, add to your wrangler.json:
wrangler.json

List Queues

View all queues in your account:
Options:
  • --page - Page number for pagination
Example Output:

Get Queue Info

Retrieve detailed information about a queue:
Shows:
  • Queue ID and name
  • Creation and modification dates
  • Producer and consumer counts
  • Settings (delivery delay, retention period)
Example:

Update Queue Settings

Modify queue configuration:
Example:

Delete a Queue

Delete a queue and all its messages:
Deleting a queue removes all messages and cannot be undone.

Queue Operations

Pause Queue

Pause message delivery to consumers:
Messages continue to be accepted but won’t be delivered to consumers.

Resume Queue

Resume message delivery:
Use Cases:
  • Temporarily stop processing during maintenance
  • Control traffic during high-load periods
  • Debug consumer issues without losing messages

Consumer Management

Add Consumer

Attach a Worker as a consumer:
Options:
  • <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
Examples:
Configuration:
wrangler.json

Update Consumer

Modify consumer settings:
Accepts same options as 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

Options:
  • --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

Events:
  • object-create - Object uploaded
  • object-delete - Object deleted
Example:

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 ID
  • timestamp - When message was sent
  • body - Message content (any JSON-serializable data)
  • attempts - Number of delivery attempts
Message Methods:
  • ack() - Mark as successfully processed
  • retry() - Retry delivery (up to max_retries)
  • retryAll() - Retry entire batch
  • ackAll() - Acknowledge entire batch
Batch Properties:
  • messages - Array of messages
  • queue - Queue name
  • retryAll() - Retry all messages
  • ackAll() - 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

Offload time-consuming tasks from request handlers:
  • Image/video processing
  • Report generation
  • Data aggregation
  • Email sending
React to events asynchronously:
  • R2 object uploads (event subscriptions)
  • User actions requiring follow-up
  • System state changes
  • Scheduled tasks
Smooth out traffic spikes:
  • Queue requests during high load
  • Process at controlled rate
  • Prevent downstream overload
  • Handle bursts gracefully
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