Azure Blob Storage Monitoring: Access, Errors, Metrics, and Alerts

Azure Blob Storage is one of the most widely used cloud storage services in the Microsoft Azure ecosystem. It stores everything from application logs and backups to images, videos, and unstructured data at scale. However, without proper observability, silent failures, unauthorized access attempts, and performance degradation can go unnoticed until they cause real problems.

This guide walks you through everything you need to know about azure blob storage monitoring: enabling diagnostic logs, reading key metrics, writing KQL queries to surface access patterns and errors, setting up alerts, and applying security monitoring. Whether you are running a production workload or troubleshooting a data pipeline, this guide gives you the practical steps to get full visibility.

Why Azure Blob Storage Monitoring Matters

Azure Blob Storage is a core dependency for a large share of Azure workloads. When something goes wrong with access, performance, or security, the impact cascades quickly. Here are the three main reasons to invest in monitoring:

• Access visibility: Know who or what is reading and writing your blobs, and detect unauthorized or anonymous access.
• Error detection: Catch authentication failures, throttling events, server errors, and client misconfiguration before they become outages.
• Performance baselines: Understand normal latency and request patterns so that deviations are immediately obvious.

Understanding the Monitoring Stack

Microsoft provides two monitoring layers for Azure Blob Storage. Understanding the difference between them is essential before enabling anything.

Azure Monitor (Recommended)

Azure Monitor is the current, recommended platform for all Azure Blob Storage monitoring. It collects platform metrics automatically every minute and provides resource logs (formerly called diagnostic logs) that you route to destinations of your choice. The official Microsoft documentation recommends using Azure Monitor logs instead of the older Storage Analytics approach.

Storage Analytics (Classic Logs) – Legacy

Storage Analytics is the older logging system that writes logs to a special container named $logs inside your storage account. Microsoft’s own documentation recommends migrating to Azure Monitor logs in Azure Monitor for new implementations. It is also worth noting that Storage Analytics logging is not available for general-purpose v2 accounts with premium performance.

Step 1: Enable Diagnostic Settings

By default, diagnostic (resource) logs for Azure Blob Storage are not collected. You must enable them explicitly. This is the most important step in the entire monitoring setup.

Via the Azure Portal

1. Open the Azure Portal and navigate to your Storage Account.
2. In the left menu, select Monitoring > Diagnostic settings.
3. Select the blob service (blobServices/default).
4. Click Add diagnostic setting.
5. Under Logs, check StorageRead, StorageWrite, and StorageDelete.
6. Under Destination details, select Send to Log Analytics workspace and choose your workspace.
7. Click Save.

Via Azure CLI

You can also enable diagnostic settings programmatically:

az monitor diagnostic-settings create \
  --resource /subscriptions/<sub-id>/resourceGroups/<rg>/providers/
    Microsoft.Storage/storageAccounts/<account>/blobServices/default \
  --name blob-diag-settings \
  --logs '[{"category":"StorageRead","enabled":true},{"category":"StorageWrite","enabled":true},{"category":"StorageDelete","enabled":true}]' \
  --workspace /subscriptions/<sub-id>/resourceGroups/<rg>/providers/
    Microsoft.OperationalInsights/workspaces/<workspace-name>

az monitor diagnostic-settings create \
  --resource /subscriptions/<sub-id>/resourceGroups/<rg>/providers/
    Microsoft.Storage/storageAccounts/<account>/blobServices/default \
  --name blob-diag-settings \
  --logs '[{"category":"StorageRead","enabled":true},{"category":"StorageWrite","enabled":true},{"category":"StorageDelete","enabled":true}]' \
  --workspace /subscriptions/<sub-id>/resourceGroups/<rg>/providers/
    Microsoft.OperationalInsights/workspaces/<workspace-name>

Log data can take up to an hour to appear in your Log Analytics workspace after enabling diagnostics for the first time. Plan for this delay when validating your setup.

Step 2: Understand the Key Metrics

Azure Monitor automatically collects platform metrics for Azure Blob Storage every minute. These are available without any additional configuration. 

Transaction Metrics (Most Critical)

Latency Metrics

Capacity Metrics

Capacity metrics for blob storage (BlobCapacity, BlobCount, ContainerCount) are collected at hourly granularity (PT1H) rather than every minute. These are useful for trending storage growth and cost forecasting but not for real-time incident detection.

Important: Capacity metrics are not exportable to Log Analytics via diagnostic settings. You must view them directly in Azure Monitor Metrics.

Step 3: Query Logs with KQL

Once diagnostic settings are enabled and logs are flowing to your Log Analytics workspace, you can use Kusto Query Language (KQL) to analyze access patterns, errors, and security events. Go to your Log Analytics workspace in the Azure Portal and use the Logs blade.

View All Blob Operations (Last 24 Hours)

StorageBlobLogs
| where TimeGenerated > ago(24h)
| project TimeGenerated, OperationName, StatusCode, CallerIpAddress,
          AuthenticationType, Uri, DurationMs
| order by TimeGenerated desc

StorageBlobLogs
| where TimeGenerated > ago(24h)
| project TimeGenerated, OperationName, StatusCode, CallerIpAddress,
          AuthenticationType, Uri, DurationMs
| order by TimeGenerated desc

Detect Failed Requests and Errors

StorageBlobLogs
| where TimeGenerated > ago(1h)
| where StatusCode >= 400
| summarize ErrorCount = count() by StatusCode, OperationName, bin(TimeGenerated, 5m)
| order by ErrorCount desc

StorageBlobLogs
| where TimeGenerated > ago(1h)
| where StatusCode >= 400
| summarize ErrorCount = count() by StatusCode, OperationName, bin(TimeGenerated, 5m)
| order by ErrorCount desc

Detect Anonymous Access to Blobs

This query identifies anonymous (unauthenticated) access attempts, which is critical for security audits:

StorageBlobLogs
| where TimeGenerated > ago(24h)
| where AuthenticationType == "Anonymous"
| project TimeGenerated, OperationName, StatusCode, CallerIpAddress, Uri
| order by TimeGenerated desc

StorageBlobLogs
| where TimeGenerated > ago(24h)
| where AuthenticationType == "Anonymous"
| project TimeGenerated, OperationName, StatusCode, CallerIpAddress, Uri
| order by TimeGenerated desc

Identify Top Callers by IP Address

StorageBlobLogs
| where TimeGenerated > ago(24h)
| summarize RequestCount = count() by CallerIpAddress
| top 20 by RequestCount desc

StorageBlobLogs
| where TimeGenerated > ago(24h)
| summarize RequestCount = count() by CallerIpAddress
| top 20 by RequestCount desc

Find Throttled Requests (503 Errors)

Throttling (HTTP 503) means Azure Storage is rate-limiting your requests. This query surfaces throttling patterns:

StorageBlobLogs
| where TimeGenerated > ago(6h)
| where StatusCode == 503
| summarize ThrottleCount = count() by bin(TimeGenerated, 1m), OperationName
| order by TimeGenerated asc

StorageBlobLogs
| where TimeGenerated > ago(6h)
| where StatusCode == 503
| summarize ThrottleCount = count() by bin(TimeGenerated, 1m), OperationName
| order by TimeGenerated asc

Step 4: Set Up Metric Alerts

Metric alerts in Azure Monitor let you define conditions on blob storage metrics and receive notifications via email, webhook, Azure Action Groups, or integrated tools like PagerDuty. Here are the most important alert rules to configure.

High Error Rate Alert (4xx/5xx)

• In the Azure Portal, go to your Storage Account > Monitoring > Alerts.
• Click New Alert Rule.
• Under Condition, choose the Transactions metric.
• Add a dimension filter: ResponseType = ClientOtherError or ServerOtherError.
• Set the threshold (for example, greater than 50 errors per 5-minute window).
• Assign an Action Group that sends email and/or calls a webhook.

Availability Drop Alert

Configure an alert on the Availability metric with a threshold below your SLA requirement (for example, alert when availability drops below 99.9% over a 5-minute period). This catches service disruptions early.

High Latency Alert

Alert on SuccessE2ELatency exceeding a baseline you establish from normal operation. A good starting threshold for most workloads is 200 ms for reads and 500 ms for writes, but adjust this to your observed baseline.

Capacity Growth Alert

Alert on BlobCapacity growing beyond a defined threshold to catch unexpected data accumulation or runaway logging pipelines before they drive up costs.

Step 5: Monitor for Security Events

Security monitoring for Azure Blob Storage deserves its own attention. The following patterns are the most important to detect:

Detecting Anonymous Access

Public blob containers expose data to the internet without authentication. Use the KQL query in the previous section and create an alert on it using a Scheduled Query Alert rule if you expect zero anonymous access:

StorageBlobLogs
| where TimeGenerated > ago(5m)
| where AuthenticationType == "Anonymous"
| summarize Count = count()
| where Count > 0

StorageBlobLogs
| where TimeGenerated > ago(5m)
| where AuthenticationType == "Anonymous"
| summarize Count = count()
| where Count > 0

Detecting Repeated Authentication Failures

StorageBlobLogs
| where TimeGenerated > ago(1h)
| where StatusCode == 403
| summarize FailureCount = count() by CallerIpAddress, bin(TimeGenerated, 5m)
| where FailureCount > 10
| order by FailureCount desc

StorageBlobLogs
| where TimeGenerated > ago(1h)
| where StatusCode == 403
| summarize FailureCount = count() by CallerIpAddress, bin(TimeGenerated, 5m)
| where FailureCount > 10
| order by FailureCount desc

This query flags IP addresses that have failed authorization more than 10 times in a 5-minute window, which may indicate a credential stuffing or enumeration attack.

Step 6: Use Azure Portal Monitoring Views

The Azure Portal provides several built-in monitoring views for blob storage that require no additional setup:

Insights

• Transactions view: Shows successful, failed, and total request counts over time.
• Performance view: End-to-end and server-side latency charts.
• Availability view: Account, Blob, File, and Table availability percentages.
• Capacity view: Account used capacity, blob capacity, queue capacity, and table capacity.
• Failures view: Breakdown of failed transactions with error classification.

Metrics Explorer

Use the Metrics blade to create custom charts by selecting any metric and applying dimension filters (for example, filter Transactions by ApiName to see counts per API operation type like GetBlob, PutBlob, or ListBlobs).

Workbooks

Azure Monitor Workbooks provide pre-built interactive dashboards for storage accounts. Navigate to Monitoring > Workbooks in your storage account and select from templates covering capacity trends, failure analysis, and performance profiling.

Third-Party and Extended Monitoring Options

For teams that need unified visibility across Azure and non-Azure services, or who want richer dashboards than what is natively available, several third-party tools provide Azure Blob Storage monitoring integrations:

CubeAPM

CubeAPM is an OpenTelemetry-native observability platform that correlates Azure Blob Storage metrics and errors with application traces and service dependencies in a single view. Instead of switching between Azure Monitor, Log Analytics, and separate dashboards, CubeAPM lets you trace a slow or failing blob operation directly back to the service call that triggered it. It ships with pre-built dashboards for blob storage metrics, latency, and errors, and requires no heavy agents to deploy. 

SigNoz

SigNoz integrates with Azure Blob Storage via the OpenTelemetry Collector with the Azure Monitor exporter. It collects metrics like Total Requests, Total Ingress/Egress, and Total Errors and allows you to build dashboards and alerts. 

Dynatrace

Dynatrace provides out-of-the-box monitoring for Azure Storage Accounts including Blob, File, Queue, and Table services. It collects transaction, latency, and availability metrics and surfaces them within its unified observability platform.

ManageEngine Applications Manager

ManageEngine Applications Manager supports Azure Storage Account monitoring with pre-configured dashboards and alerting for storage performance, availability, and capacity metrics.

Best Practices for Azure Blob Storage Monitoring

• Enable diagnostic settings from day one, not after an incident.
• Send logs to a Log Analytics workspace rather than just a storage account to enable KQL queries and alert rules.
• Establish metric baselines during normal operation before setting alert thresholds.
• Monitor both SuccessE2ELatency and SuccessServerLatency to differentiate Azure-side from client-side latency issues.
• Use dimension filtering on the Transactions metric (by ResponseType and ApiName) to understand the error breakdown before setting alert thresholds.
• Regularly review anomalous caller IPs and anonymous access patterns, especially in shared environments.
• For high-volume storage accounts, consider routing logs to Azure Event Hub for stream processing rather than Log Analytics to control costs.
• Test your alert rules by deliberately triggering conditions (for example, sending a request to a non-existent blob) during a maintenance window.

Conclusion

Effective azure blob storage monitoring is not a single task but a combination of steps: enabling diagnostics, understanding the right metrics, writing targeted KQL queries, setting alert rules, and applying security monitoring. The native Azure Monitor stack covers most production needs, and third-party tools like CubeAPM, SigNoz, and Dynatrace extend that visibility when you need cross-service correlation.

Start with diagnostic settings and the four core metric alerts (errors, availability, latency, and capacity). From there, layer in KQL queries for access analysis and security events. With these pieces in place, you will have the observability foundation needed to operate Azure Blob Storage reliably at any scale.

Disclaimer: Azure features, pricing, and availability can change over time. Always verify details against the official Microsoft Azure documentation before making production decisions. Test and adapt any KQL queries or CLI commands for your own environment.

FAQs