Azure Queue Storage provides reliable message queuing for asynchronous communication between application components. Cloudmon monitors queue capacity, message counts, transaction volume, and latency across all your Queue Storage resources.
Azure Queue Storage decouples application components by storing messages that can be processed asynchronously. It is commonly used in event-driven architectures and background task processing. Cloudmon automatically discovers all Queue Storage resources linked to your monitored Azure account. Navigate to Cloud → Azure → [Select Account] → Azure Queue Storage to view the full list. Click any resource name to open its detailed monitoring view.
The list displays all discovered Queue Storage resources with the following details:
| Column | Description |
| Name | The name of the resource as configured in Azure. |
| Kind | The storage account type, for example, StorageV2. |
| Resource Group | The Resource Group this resource belongs to. |
| Location | The Azure region where the resource is deployed. |
| Creation Time | The date and time the resource was created. |
| Size | The replication and performance tier, for example, Standard_LRS or Standard_GZRS. |
| Actions | Toggle to enable or disable monitoring, and an edit icon to update the configuration. |
Selecting a Queue Storage resource opens its detail page. The overview displays key details, including the Primary Location, SKU, Resource Group, Subscription, Status, and Monitoring Status, as well as other configuration and availability information.
Cloudmon collects key metrics such as Queue Capacity, Queue Count, Queue Message Count, Transactions, Ingress, and Egress, as well as other performance indicators, including latency and availability. These are displayed as time-series charts for the selected time period.
Lists all queues within the selected resource by name. Use the search bar to filter by queue name.
Surfaces actionable insights from Azure Advisor specific to this Queue Storage resource. Recommendations may include enabling zone redundancy to ensure messages remain accessible during a regional failure, enforcing a minimum TLS version for secure communication, or restricting public network access to reduce exposure. Each recommendation shows its impact level and category across Cost, Security, High Availability, Performance, and Operational Excellence.
| Symptom | Likely Cause | Fix |
| Resource not appearing in the list | Discovery has not run since the resource was created, or the service was not selected during Azure account setup | Trigger a manual rediscovery from Settings → Monitoring → Probes → Azure, or edit the account to enable the missing service |
| Metrics showing no data | The resource may have had no activity during the selected time window, or polling has not completed yet | Wait for the next polling cycle or reduce the selected time range to a period with known activity |
| Availability dropping below 100% | The storage service experienced a transient error or outage during the monitored period | Review the metric timeline to identify when the drop occurred and cross-reference with Azure Service Health |
| Alarms not triggering as expected | Alarm thresholds may not be configured for this resource | Go to Settings and add or review alarm triggers |
| Queue Message Count growing unexpectedly | Messages are being enqueued faster than they are being processed, indicating a consumer bottleneck | Review the consuming application for processing delays and scale consumers if needed |
| High transaction count with low message throughput | Frequent polling from consumers checking for messages that are not yet available | Implement long-polling or exponential backoff in the consuming application to reduce unnecessary transactions |