Queues Observability
The Queues observability tab provides visibility into your queue operations, helping you monitor message throughput, consumer performance, message age, and retries across all your queues.
You can access Queues observability at the project level through the Observability tab:
- Navigate to your project dashboard
- Click on the Observability tab in the left sidebar
- Select Queues from the horizontal tabs at the top
The Queues tab shows all queues in your project with real-time metrics and historical trends.
When viewing the Queues tab at the project level, you can see:
| Metric | Description |
|---|---|
| Messages/s | Number of messages sent to the queue per second |
| Queued | Total number of messages sent to the queue over the time period |
| Received | Total number of messages received by consumers |
| Deleted | Total number of messages successfully processed and deleted |
| Redeliveries | Receives beyond a message's first attempt |
Each row in the table includes sparkline charts showing how these metrics have changed over time. You can click on any queue to view detailed metrics for that specific queue.
When you click on a specific queue, you can see detailed charts and breakdowns:
Queue Activity per Second: Line chart comparing the rate at which messages are published, received, and deleted. This helps you understand:
- Peak processing times and traffic patterns
- Whether consumers are keeping up with incoming messages
- Whether consumers delete the messages they receive, or leave them to expire and redeliver
Max Message Age: Line chart showing how long the oldest message waited before a consumer received it, broken down by consumer group. This metric helps you identify:
- Consumer lag or backlog issues
- Whether messages are being processed in a timely manner
- Potential problems with specific consumer groups
Retry Depth: Line chart showing the highest receive count any message reached, broken down by consumer group. A queue whose messages are each received once stays at 1. Use this chart to find which consumer group is retrying, then correlate the climb with a deploy or a downstream outage.
Consumers table: A detailed table showing all consumer groups for the queue with the following columns:
| Column | Description |
|---|---|
| Consumer Group | Name of the consumer group |
| Processed/s | Messages processed per second by this consumer group |
| Received | Total messages received with sparkline chart |
| Deleted | Total messages successfully deleted with sparkline chart |
| Redeliveries | Receives by this consumer group beyond a message's first attempt |
The queue redelivers a message when a consumer receives it but never deletes it. The lease expires and the next consumer to poll receives the message again, counting one more receive. Returning { afterSeconds: n } from the SDK's retry callback sets the remaining lease to n seconds, and the receive that follows counts the same way.
Redeliveries counts those repeat receives. Retry Depth reports the highest attempt number any single message reached, so the two answer different questions:
| Pattern | What it means |
|---|---|
| Retry Depth of 1 | No message has been received more than once |
| High Redeliveries, low Retry Depth | Failures spread across many messages rather than concentrated in one |
| Rising Retry Depth | At least one message keeps failing and the queue keeps retrying it |
A Retry Depth that climbs over time points to a poison message: one payload your consumer cannot process, taking one more receive on every cycle. Fix the handler, or return { acknowledge: true } from the retry callback so the message stops recirculating.
Both metrics are also available under Queue Actions on the Observability Query tab, where you can group them by queue name, consumer group, or event type.
A rising Retry Depth is the earliest sign that a consumer is failing every delivery. Because messages stay pinned to the deployment that published them, a rolled-back deployment can keep failing and retrying for the full message retention period without showing up in production traffic.
For projects with Observability Plus enabled, teams can create a custom monitor on Retry Depth. The Queue Retry Depth preset in the monitor wizard sets this up: it triggers when the maximum Retry Depth in the project exceeds 5 within a 5-minute window, which a message reaches within minutes under the default retry delay when its consumer fails every time.
When the alert fires, open the queue's Consumers table to find the consumer group, then check function duration grouped by deployment on the Query tab to see which deployment the retries are running on and what they cost. See Cost of failed deliveries for what to do next.
Was this helpful?