Blob Container Count Metric Shows Half the Actual Value When Using Average Aggregation

Question

Blob Container Count Metric Shows Half the Actual Value When Using Average Aggregation

cloudteam 60

Hi Team,

I am seeing inconsistent behavior with the Blob Container Count (ContainerCount) metric for a Storage Account in Azure Monitor.

Scenario:

I deployed a Storage Account and created 2 blob containers. Checked the value in Azure monitor metrics section (Storage Account → Monitoring → Metrics → Metric Namespace: Blob) and Storage browser page (Storage Account → Blob containers → Number of containers)
Storage Browser → Number of containers shows: 2
Azure Monitor Metrics → Blob Container Count (aggregation: Average) shows: 1
After increasing the number of containers to 5,
- Storage Browser shows: 5
- Azure Monitor Metrics (Average) shows: 2.5

It appears that the value in Storage Browser is the same as the available containers in the Storage Account but in Azure monitor metrics page always displays half of the actual container count when the aggregation is Average.

Please find the attachments for reference. AzureMonitorMetrics.png & StorageBrowser.png

Observations:

As per documentation, Azure portal & Metric definition API response, “Average” is the only aggregation supported for Blob Container Count (ContainerCount) metric.
However, when I try fetching response for Azure Storage Account Metrics REST API using "total" aggregation (which is not listed as supported), the API returns the correct full container count (5).
Previously I have faced, using an unsupported aggregation in Metrics API returned an error. Now it returns data without error.

Questions:

How is the Blob Container Count (ContainerCount) metric calculated internally when using the "Average" aggregation? Why does it show half the number of blob containers?
Is it safe to use the "total" aggregation in the Metrics API even though the Azure documentation and Metric Definition API response list only “Average” as supported?
- Has behavior changed recently?
- Could “total” stop be working again in the future since it's not officially supported?

I would appreciate clarification on this metric behavior.

Thanks in advance for the clarification!

cloudteam 60 Reputation points

2025-12-05T06:26:41.2766667+00:00

Hi Suchitra,

Thank you for the clarification.

Regarding the Container Count (Average) behavior — in my case, I did not create or delete any containers during the middle of the time period I selected (e.g., Last 4 hours or a custom time range covering whole hours). The container count remained constant throughout the entire period. However, the Average value consistently shows exactly half of the actual number of containers.

Could you please help confirm why this happens even when there is no mid-hour or mid-period change in container count?

The rest of the explanation is clear. Thank you.
Suchitra Suregaunkar 3,545 Reputation points Microsoft External Staff Moderator

2025-12-05T13:30:15.24+00:00
Hello cloudteam

if the container count was truly constant for the entire selected period, the metric should normally show the actual count when using Average. If it still shows exactly half, here are the most likely reasons:

Time Grain vs. Chart Aggregation:

The Average you see in Metrics Explorer is calculated per time grain bucket, then aggregated again for the chart.

If your chart’s time range (e.g., 4 hours) is combined with a time grain larger than the metric’s native sampling (PT1H), the portal may compute an additional average across multiple buckets.

Example: If you select Last 4 hours with time grain = 4 hours, the portal averages the hourly samples (all equal to your container count) over 4 hours. If the portal divides by the number of buckets incorrectly or applies normalization, you can see half or another fraction.

Metric Namespace and Dimension Filters:

Ensure you are using Metric namespace = Blob and the metric ContainerCount without any dimension filter (e.g., AccessLevel).

If the chart is scoped to a dimension (like AccessLevel=Private), you might only see part of the total count.

Portal Visualization Quirk: Metrics Explorer sometimes applies “average of averages” when you select aggregation = Average at the chart level.

“The chart shows the aggregation across all time buckets in the selected range.”

If you have 4 hourly buckets, each with value N, the portal computes (N + N + N + N) / 4 = N. But if the portal interprets the metric as normalized per hour and divides again by the number of hours, you can see half or another fraction.

To confirm:

In Metrics Explorer, set:

Time range = 1 hour

Time grain = 1 hour

Aggregation = Average

If the value now matches the actual container count, the discrepancy is due to chart-level aggregation across multiple buckets.

If you need the true container count:

Use List Containers API or SDK: Reference: https://learn.microsoft.com/en-us/rest/api/storageservices/list-containers2?tabs=microsoft-entra-id

Or in Metrics Explorer, select time range = 1 hour and time grain = 1 hour to avoid cross-bucket averaging.

Thanks,

Suchitra.

1 answer

Your answer

cloudteam 60 Reputation points

2025-12-05T06:26:41.2766667+00:00

Hi Suchitra,

Thank you for the clarification.

Regarding the Container Count (Average) behavior — in my case, I did not create or delete any containers during the middle of the time period I selected (e.g., Last 4 hours or a custom time range covering whole hours). The container count remained constant throughout the entire period. However, the Average value consistently shows exactly half of the actual number of containers.

Could you please help confirm why this happens even when there is no mid-hour or mid-period change in container count?

The rest of the explanation is clear. Thank you.

Answer 1

Hello cloudteam

Thank you for posting your query on Microsoft Q&A platform.

Blob Container Count (ContainerCount) in Azure Monitor appears to show half the actual number of containers when you use the Average aggregation in Metrics Explorer.

For the resource type Microsoft.Storage/storageAccounts/blobServices, the metric ContainerCount is defined with Aggregation = Average and Time grain = PT1H (hourly). It can also be split by the AccessLevel dimension.
In Azure Monitor, Average is calculated over the selected time grain. If your container count changes mid‑hour (e.g., from 0 to 5 at the 30‑minute mark), the hour’s Average becomes the time‑weighted mean: (0 for 30 min + 5 for 30 min) / 60 min = 2.5. That’s why you observed 1 (for 2 created halfway through the hour) and 2.5 (for 5 created halfway through). This is the documented aggregation behavior of Azure Monitor metrics.

The Metrics Explorer value is an hourly average, not a “point‑in‑time” snapshot. It will only equal your current container count when the count is stable for the entire hour.

Reference: https://learn.microsoft.com/en-us/azure/azure-monitor/metrics/metrics-aggregation-explained

As a resolution:

If you need the precise current count (not an hour‑average):

Use the Storage (data‑plane) API – List Containers Call List Containers on the Blob service and count the returned items. This returns the exact container count at query time.

REST: List Containers (Blob service)
SDK examples: List blob containers (.NET), List blob containers (JavaScript/TypeScript)

Reference: https://learn.microsoft.com/en-us/rest/api/storageservices/list-containers2?tabs=microsoft-entra-id

https://learn.microsoft.com/en-us/azure/storage/blobs/storage-blob-containers-list

Use the Resource Provider (management‑plane) API If you prefer the ARM path, Blob Containers – List under the Storage Resource Provider lists containers for the account.

Reference: https://learn.microsoft.com/en-us/rest/api/storagerp/blob-containers/list?view=rest-storagerp-2025-06-01&tabs=HTTP

If you must use Metrics Explorer Plot ContainerCount with time grain = 1 hour and select an hour window during which your number of containers did not change. The Average for that hour will match the actual count.

About using total (Sum) aggregation in the Metrics REST API:

The Metrics List REST API does accept an aggregation parameter (e.g., average, minimum, maximum, total), but each metric publishes the aggregations it actually supports via its definition. You should only request supported types for that metric.
For ContainerCount specifically, the supported aggregation is only Average (per the Storage Blob Services supported metrics table). Using total may return data today, but it’s not documented for this metric and therefore not guaranteed.

Use only documented aggregations from the metric’s definition. For an exact count, use the List Containers API rather than relying on an undocumented aggregation.

https://learn.microsoft.com/en-us/azure/azure-monitor/reference/supported-metrics/microsoft-storage-storageaccounts-blobservices-metrics and https://learn.microsoft.com/en-us/rest/api/storageservices/list-containers2?tabs=microsoft-entra-id

To answer to your questions:

1.How is ContainerCount (Average) calculated? Why does it show half?

It’s the time‑weighted average over the one‑hour time grain. If the count changes halfway through the hour, the hour’s average can be ~half of the final value. This is by design.

2.Is it safe to use total aggregation for this metric?

No. ContainerCount only lists Average as supported. Requests for total are undocumented for this metric and not guaranteed to be correct or stable. Use Average (with a stable hour) or use List Containers for an exact count.

3.Has behavior changed recently?

There is no published change that adds total support to ContainerCount. Current documentation still shows Average‑only with PT1H sampling.

4.Could total stop working in the future since it’s not officially supported?

Yes. Because it’s not a documented aggregation for ContainerCount, Azure can change or reject such requests at any time. Stick to supportedAggregationTypes and the metric definition

If you have any other queries, please do let us know.

Thanks,

Suchitra.

Share via

Blob Container Count Metric Shows Half the Actual Value When Using Average Aggregation

1 answer

Your answer