Azure Service Bus is a fully managed enterprise message broker that decouples applications and services using queues and topics. When messages stop flowing or consumers fall behind, your entire application pipeline can stall. Monitoring Azure Service Bus is not optional; it is a production requirement.
This guide explains how to monitor Azure Service Bus queues and topics using Azure Monitor, diagnostic logs, alerts, and the Azure CLI. It also covers common monitoring challenges, recommended metrics, alert thresholds, and when third-party tools add value.
Key Takeaways
- Azure Monitor is the built-in, zero-setup way to view Service Bus metrics such as active message count, dead-letter count, and throughput.
- The most critical metrics to watch are Active Message Count, Dead-Letter Message Count, Incoming Messages, Outgoing Messages, and Server Errors.
- Dead-letter queue (DLQ) growth almost always signals a processing bug; set an alert to trigger on any DLQ increase.
- Diagnostic logs must be explicitly enabled; they are not on by default.
- For topic subscriptions, use the ‘Split by’ filter in Azure Monitor to get per-subscription breakdowns, as the portal shows aggregate topic metrics by default.
- Azure Workbooks and custom dashboards consolidate multi-queue and multi-topic views into a single screen.
- Third-party observability tools (New Relic, ManageEngine, Nodinite) extend native monitoring with cross-service correlation, richer alerting, and no-code dashboards.
Azure Service Bus Queues vs. Topics: What You Are Monitoring
Before setting up monitoring, it helps to understand what entities you are dealing with.
A queue is a first-in, first-out (FIFO) message store. One sender puts a message in; one receiver pulls it out. Queues are ideal for point-to-point communication between services.
A topic is a publish-subscribe channel. One sender publishes a message to the topic; multiple subscriptions receive a copy of that message independently. Each subscription acts like its own queue with its own active message count and dead-letter queue.
Both queues and topic subscriptions expose the same core metrics through Azure Monitor. The monitoring approach is identical; the only difference is how you filter the data.
Key Metrics to Monitor
Azure Service Bus exposes metrics through Azure Monitor. These metrics are available without any configuration change and are retained for 93 days by default. Below is a complete reference of the metrics that matter most in production.
| Metric | What It Measures | Why It Matters |
| Active Message Count | Messages waiting in queue or subscription | Primary backlog signal, rising count means consumers are falling behind |
| Dead-Letter Message Count | Messages moved to DLQ after failed processing | Any increase = processing errors or poison messages; alert on this immediately |
| Incoming Messages | Rate of messages published per unit time | Sudden drop to zero = publisher is down |
| Outgoing Messages | Rate of messages consumed per unit time | Sudden drop = consumer is stuck or stopped |
| Server Errors | Internal Service Bus platform errors | Non-zero = Azure-side issue; open a support ticket |
| Throttled Requests | Requests rejected due to quota or throughput limits | Any value = namespace hitting its tier ceiling |
Active Message Count: Your Primary Health Signal
Active Message Count is the number of messages in a queue or subscription that are waiting to be received. A steadily rising count means consumers are processing messages more slowly than they are arriving. This is the first metric to alert on.
A healthy queue shows active message count fluctuating around a low baseline. A queue that grows without bound is a consumer outage waiting to be discovered.
How to View Metrics in the Azure Portal
Azure Monitor surfaces Service Bus metrics directly inside the Azure Portal with no additional setup.
Steps:
- Open the Azure Portal and navigate to your Service Bus namespace.
- In the left menu, select Metrics under the Monitoring section.
- Click the Metric dropdown and choose the metric you want, for example Active Messages.
- Set a time range (Last 1 hour, Last 24 hours, Last 7 days).
- To drill into a specific queue or topic, click Add filter, select Entity Name, and choose the entity.
- To compare multiple queues on one chart, click Apply splitting and split by Entity Name.
For topic subscriptions specifically, use the Split by feature. Azure Monitor does not automatically separate topic metrics by subscription in the default view; you must apply the split explicitly.
How to View Metrics via Azure CLI
For automated checks or scripting, the Azure CLI gives you metric values on demand.
Get active message count for a queue (last 1 hour, 1-minute granularity):
az monitor metrics list \ --resource /subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.ServiceBus/namespaces/<namespace> \ --metric "ActiveMessages" \ --interval PT1M \ --start-time $(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%SZ) \ --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \ --filter "EntityName eq '<queue-name>'" \ --output tableGet dead-letter count for a queue:
az monitor metrics list \ --resource /subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.ServiceBus/namespaces/<namespace> \ --metric "DeadLetteredMessages" \ --filter "EntityName eq '<queue-name>'" \ --output tableEnabling Diagnostic Logs
Metrics tell you counts and rates. Diagnostic logs tell you what actually happened: which operations ran, which failed, and why. Diagnostic logs are not enabled by default.
To enable diagnostic logs:
- Open your Service Bus namespace in the Azure Portal.
- Under Monitoring, select Diagnostic settings.
- Click Add diagnostic setting.
- Select the log categories you want. Recommended: Operational Logs (management events like create/delete) and Runtime Audit Logs (send, receive, complete operations).
- Choose a destination: Log Analytics workspace (recommended for querying), a Storage Account (for archiving), or an Event Hub (for streaming to a SIEM).
- Save the setting. Logs begin flowing within a few minutes.
Once logs are in Log Analytics, you can query them with KQL. For example, to find all failed receive operations:
AzureDiagnostics| where ResourceType == "NAMESPACES"| where Category == "OperationalLogs"| where ResultType == "Failed"| where OperationName contains "Receive"| project TimeGenerated, OperationName, ResultDescription, EntityName| order by TimeGenerated descSetting Up Alerts
Viewing metrics manually is reactive. Alerts make monitoring proactive. Azure Monitor alerts fire automatically when a metric crosses a threshold you define.
| Alert Name | Metric | Condition | Severity |
|---|---|---|---|
| Queue Backlog Growing | Active Messages | > 500 for 5 min | Warning |
| Consumer Stopped | Active Messages | > 1000 for 10 min | Critical |
| Dead-Letter Spike | Dead-Letter Messages | > 0 (any increase) | Warning |
| Publisher Down | Incoming Messages | = 0 for 5 min | Critical |
| Platform Error | Server Errors | > 0 | Critical |
| Namespace Throttling | Throttled Requests | > 0 | Warning |
| Namespace CPU High | CPU Usage (Premium) | > 70% | Warning |
| Namespace Storage High | Namespace Size Used % | > 80% | Warning |
Creating an Alert via Azure Portal
- Open your Service Bus namespace and go to Alerts under Monitoring.
- Click New alert rule.
- Select the signal (metric). For example, choose Active Messages.
- Set the condition: Operator = Greater than, Threshold = 500, Aggregation = Average, Evaluated over = Last 5 minutes.
- Under Actions, select or create an Action Group to define who is notified and how (email, SMS, webhook, PagerDuty, etc.).
- Give the alert a name and save.
Creating an Alert via Azure CLI
az monitor metrics alert create \ --name 'HighActiveMessages' \ --resource-group <rg> \ --scopes /subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.ServiceBus/namespaces/<namespace> \ --condition "avg ActiveMessages > 500" \ --window-size 5m \ --evaluation-frequency 1m \ --action <action-group-resource-id> \ --description 'Alert when active messages exceed 500'Tip: Use dynamic thresholds for high-variance queues. Azure Monitor will learn the historical pattern and alert only on true anomalies, reducing alert fatigue.
Monitoring the Dead-Letter Queue
The dead-letter queue (DLQ) holds messages that could not be processed after the maximum delivery count was reached, or that were explicitly dead-lettered by the application. Monitoring the DLQ is critical because every message there represents a lost transaction.
What causes DLQ growth:
- Processing exceptions that are not caught, causing the message to be abandoned repeatedly until the delivery count limit is hit.
- TTL (Time to Live) expiry: the message was not consumed before its TTL elapsed.
- Message size or content validation failures.
- Application logic that intentionally dead-letters messages due to invalid payload.
Monitoring steps:
- Alert on any non-zero increase in Dead-Lettered Messages count (see alert table above).
- Regularly inspect DLQ messages in the Azure Portal: go to the queue or subscription, click the dead-letter sub-queue, and view messages.
- Use the Azure Service Bus Explorer (open-source tool by Paolo Salvatori) to browse, export, and resubmit DLQ messages: https://github.com/paolosalvatori/ServiceBusExplorer
- For topics, each subscription has its own DLQ. Monitor each subscription separately.
A dead-letter alert that fires once is a bug. A DLQ alert that fires continuously is a production incident. Treat them accordingly.
Monitoring Topic Subscriptions
Topic subscriptions are the most commonly under-monitored part of Azure Service Bus. The default Azure Portal view shows aggregate metrics for the topic as a whole. It does not break down by individual subscription.
To see per-subscription metrics:
- In the Metrics blade for your namespace, select Active Messages as the metric.
- Click Add filter and filter by Entity Name. For subscriptions, the entity name format is: <topic-name>/Subscriptions/<subscription-name>.
- Alternatively, apply splitting by Entity Name to see all subscriptions plotted on the same chart.
Common issues with topic subscriptions:
- A slow or stopped consumer on one subscription backs up that subscription only, while other subscriptions remain healthy. Per-subscription alerts catch this early.
- SQL filter rules can silently drop messages that do not match any subscription filter. If incoming count is high but active count on subscriptions is zero, review your filter rules.
- Auto-forwarding from a subscription to a queue introduces a second entity to monitor. Track the forwarding queue as well.
Azure Monitor Insights for Service Bus
Azure Monitor includes a pre-built Insights view for Azure Service Bus. This is a curated workbook that surfaces the most important metrics without requiring you to build custom charts.
To access it:
- Open your Service Bus namespace in the Azure Portal.
- In the left menu, select Insights under Monitoring.
- The Insights view shows Overview (requests, messages, connections), Messages (incoming and outgoing rates), Connections, and a per-entity breakdown.
Building Custom Dashboards with Azure Workbooks
For teams managing multiple queues and topics across multiple namespaces, the default Insights view is not enough. Azure Workbooks let you build fully custom, interactive dashboards that combine metrics, log queries, and text in a single view.
A practical Service Bus Workbook typically includes:
- A multi-namespace overview table showing active message count, DLQ count, and throughput for every monitored entity.
- A time-series chart of active messages per queue, segmented by entity name.
- A KQL query showing recent failed operations from diagnostic logs.
- A DLQ trend chart with threshold annotation lines.
To create a Workbook, open Azure Monitor, go to Workbooks, and click New. Workbooks support parameters (like namespace or time range selectors) that make them reusable across environments.
Common Azure Service Bus Monitoring Challenges
Azure Monitor covers the basics well, but teams running Service Bus at scale consistently run into these gaps:
Service Bus sits between producers and consumers. Azure Monitor shows you the queue depth, but it does not trace an individual message end-to-end across the system. Correlating a slow queue with a slow downstream database or a failed Azure Function requires distributed tracing, typically through Application Insights or OpenTelemetry.
As described above, topic subscription metrics require explicit filtering. Teams relying on out-of-the-box dashboards often miss subscription-level problems.
Azure Monitor metrics show counts and rates, not message content. Debugging a DLQ spike requires manually inspecting messages in the portal or using Service Bus Explorer. For high-volume queues, this is time-consuming.
Queue depth fluctuates with traffic patterns. A static threshold of 500 messages will trigger noisy alerts overnight when traffic drops. Use dynamic thresholds or time-aware alert rules to reduce false positives.
CPU and memory metrics for namespace-level resource monitoring are only available on the Premium tier. Standard tier namespaces have no infrastructure-level metrics.
Third-Party Monitoring Tools
Native Azure Monitor tooling covers most production needs. Third-party tools become valuable when you need cross-cloud visibility, richer alerting logic, or centralized observability across Service Bus and other services.
CubeAPM
CubeAPM is a full-stack APM and observability platform that provides out-of-the-box monitoring for Azure Service Bus queues and topics. It surfaces active message counts, dead-letter queue trends, throughput, and latency on pre-built dashboards without manual instrumentation. CubeAPM correlates Service Bus metrics with application traces and logs in the same view, making it straightforward to find whether a growing queue backlog is caused by a slow consumer, a code exception, or a downstream dependency.
New Relic
New Relic integrates with Azure Monitor through the Azure Native New Relic Service. It pulls Service Bus metrics into the New Relic platform, where you can correlate them with application traces and infrastructure metrics.
ManageEngine Applications Manager
Applications Manager provides a dedicated Service Bus monitoring module that tracks queues, topics, and subscriptions with pre-built dashboards and auto-discovery.
IBM MQ (Hybrid Scenarios)
For organisations that bridge on-premises IBM MQ with Azure Service Bus, IBM provides documentation on monitoring Service Bus within hybrid integration pipelines.
Conclusion
Monitoring Azure Service Bus queues and topics is straightforward once you know which metrics to watch and how to filter them. Start with Azure Monitor for zero-configuration metric collection. Enable diagnostic logs for operational visibility. Set alerts on active message count, dead-letter count, and server errors before going to production. Use Insights and Workbooks to build dashboards your team can actually use.
For topic subscriptions, always apply entity-level filtering. Aggregate topic metrics hide individual subscription problems. A single slow consumer on one subscription will not show up in namespace-level charts.
If you need cross-service correlation, message tracing, or no-code DLQ management, layer in a third-party tool. Azure Monitor handles the numbers; full observability also requires context.
⚠️ Disclaimer
This article reflects Azure Service Bus and Azure Monitor documentation as of the publication date. Azure services change frequently — always verify against the official Microsoft Learn documentation before making implementation decisions.
FAQs
1. How do I check the active message count for an Azure Service Bus queue?
Open your Service Bus namespace in the Azure Portal, go to Metrics under Monitoring, select the Active Messages metric, and filter by Entity Name to scope it to a specific queue. You can also retrieve this value via the Azure CLI using the az monitor metrics list command with the ActiveMessages metric and an EntityName filter.
2. Why are messages going to the dead-letter queue?
Messages land in the dead-letter queue (DLQ) for three main reasons: the maximum delivery count was exceeded because the consumer kept abandoning the message; the message TTL (Time to Live) expired before it was consumed; or the application explicitly dead-lettered the message due to a validation failure. Check the DeadLetterReason and DeadLetterErrorDescription properties on the message to identify the exact cause.
3. How do I monitor individual topic subscriptions, not just the topic as a whole?
In the Azure Portal Metrics blade, apply an Add filter on Entity Name. For subscriptions, the entity name follows the pattern <topic-name>/Subscriptions/<subscription-name>. Alternatively, use Apply splitting by Entity Name to plot all subscriptions on the same chart and compare them side by side.
4. Are diagnostic logs enabled by default for Azure Service Bus?
No. Diagnostic logs are off by default. You must explicitly enable them by going to your Service Bus namespace, opening Diagnostic settings under Monitoring, and adding a diagnostic setting that routes logs to a Log Analytics workspace, a Storage Account, or an Event Hub.
5. What is the difference between Azure Monitor Metrics and diagnostic logs for Service Bus?
Metrics are numeric time-series data (counts, rates, sizes) aggregated at regular intervals. They are ideal for dashboards and threshold-based alerts. Diagnostic logs are structured, per-operation event records that capture what actually happened: which send or receive operation ran, which entity it touched, whether it succeeded or failed, and why. Use metrics for alerting and diagnostics logs for root cause investigation.