Blob metric showing intermittent gaps since mid-May 2026

Question

Blob metric showing intermittent gaps since mid-May 2026

Ryota Shimizu 25

For one of my storage accounts in Japan East region, the Blob Capacity and Blob Count metrics (metric namespace: Blob, aggregation: Avg, time grain: 1 hour / PT1H) started showing intermittent missing data points in mid-May 2026. Until around May 13 they were emitted every hour with no gaps — the line chart was a continuous solid line. From around May 13 onward, the data points become intermittent.

I switched the chart to a scatter plot (which only plots a dot when a value actually exists) to look at the raw data points. In the attached window (5/12–5/19 UTC) the pattern is clear:

through about May 13: dots are dense and evenly spaced (hourly, no gaps).
after about May 13: the cadence drops to a coarser, sparser spacing, with clusters and gaps in between.

Both metrics show the same behavior. The values themselves look correct and keep tracking normally (Blob Count around 159, Blob Capacity around 14 MiB), so this does not look like data loss — it seems like only the emission frequency of the metrics has dropped. I could not find any related Azure Service Health incident or a public known issue.

Questions:

Is anyone else seeing intermittent gaps in Blob Capacity or Blob Count since around mid-May 2026?
Has there been any recent change to how these capacity metrics are emitted (e.g., cadence)?
Will the data points missing during this period be backfilled later, or are they permanently absent?

Thanks in advance for any insight!

metrics

0 comments

Answer accepted by question author

0 additional answers

Your answer

Answer 1

Amira Bedhiafi 43,046 MVP Volunteer Moderator

Hello !

Thank you for posting on MS Learn Q&A.

Blob Capacity and Blob Count are still listed as Azure Monitor Blob service capacity metrics with PT1H / 1-hour time grain and Average aggregation and these metrics are emitted hourly but they are computed by a background process and updated multiple times a day.

So the behavior you are seeing is not something I would interpret as blob data loss. Since both BlobCapacity and BlobCount show the same gaps, while the values remain consistent this looks more like a metrics emission or Azure Monitor ingestion issue for those capacity metrics.

Azure Monitor scatter charts only show a dot when a value exists. Missing dots mean the metric returned null / no data for that time grain, not zero.

PT1H is the supported time grain but capacity metrics are background calculated and I would not assume the missing historical points will be backfilled Azure Monitor stores whatever metric samples the resource provider emits. If the points remain missing after the normal processing delay, treat them as absent unless Microsoft Support confirms a backend recovery.

You can query the metric directly through Azure Monitor Metrics API or CLI for the same time range. For example:

az monitor metrics list \
  --resource "/subscriptions/<subId>/resourceGroups/<rg>/providers/Microsoft.Storage/storageAccounts/<account>/blobServices/default" \
  --metric BlobCapacity BlobCount \
  --interval PT1H \
  --aggregation Average \
  --start-time 2026-05-12T00:00:00Z \
  --end-time 2026-05-19T00:00:00Z

If the API also returns missing hourly buckets, then this is not a charting issue.

Ryota Shimizu 25

@Amira Bedhiafi
Thank you!
I queried the Metrics API as you suggested, and the gaps show up there too — so this is an actual emission gap, not a charting artifact.

A few findings from the raw data (5/12–5/19 UTC, PT1H):

Out of 168 hourly buckets, 17 are missing (the timeStamp is returned but the average field is absent).
The gaps only start at 2026-05-14 21:00 UTC. Everything before that (5/12 00:00Z through 5/14 20:00Z) is fully continuous, and the prior week (5/6–5/13) was complete as well. So this is a change in behavior from mid-May, not the normal background-calc cadence.
BlobCapacity and BlobCount are missing at exactly the same 17 timestamps — every missing hour lines up between the two metrics. That points to the shared background process that produces both capacity metrics failing to emit for those specific hours, rather than a per-metric quirk.
These buckets are several days old and still empty, so it doesn't look like delayed backfill — they appear to be permanently absent, which matches your point.

I used jq to extract the timestamps where the value was missing. Missing timestamps for BlobCapacity and BlobCount :

$ az monitor metrics list \
  --resource $resource \
  --metric BlobCapacity \
  --interval PT1H \
  --aggregation Average \
  --start-time 2026-05-12T00:00:00Z \
  --end-time 2026-05-19T00:00:00Z \
| jq '.value[].timeseries[].data[] | select(has("average")|not)'

{
  "timeStamp": "2026-05-14T21:00:00Z"
}
{
  "timeStamp": "2026-05-15T05:00:00Z"
}
{
  "timeStamp": "2026-05-15T20:00:00Z"
}
{
  "timeStamp": "2026-05-16T08:00:00Z"
}
{
  "timeStamp": "2026-05-16T09:00:00Z"
}
{
  "timeStamp": "2026-05-16T15:00:00Z"
}
{
  "timeStamp": "2026-05-16T18:00:00Z"
}
{
  "timeStamp": "2026-05-17T02:00:00Z"
}
{
  "timeStamp": "2026-05-17T04:00:00Z"
}
{
  "timeStamp": "2026-05-17T12:00:00Z"
}
{
  "timeStamp": "2026-05-17T14:00:00Z"
}
{
  "timeStamp": "2026-05-17T17:00:00Z"
}
{
  "timeStamp": "2026-05-18T02:00:00Z"
}
{
  "timeStamp": "2026-05-18T04:00:00Z"
}
{
  "timeStamp": "2026-05-18T09:00:00Z"
}
{
  "timeStamp": "2026-05-18T16:00:00Z"
}
{
  "timeStamp": "2026-05-18T22:00:00Z"
}

$ az monitor metrics list \
  --resource $resource \
  --metric BlobCount \
  --interval PT1H \
  --aggregation Average \
  --start-time 2026-05-12T00:00:00Z \
  --end-time 2026-05-19T00:00:00Z \
| jq '.value[].timeseries[].data[] | select(has("average")|not)'

{
  "timeStamp": "2026-05-14T21:00:00Z"
}
{
  "timeStamp": "2026-05-15T05:00:00Z"
}
{
  "timeStamp": "2026-05-15T20:00:00Z"
}
{
  "timeStamp": "2026-05-16T08:00:00Z"
}
{
  "timeStamp": "2026-05-16T09:00:00Z"
}
{
  "timeStamp": "2026-05-16T15:00:00Z"
}
{
  "timeStamp": "2026-05-16T18:00:00Z"
}
{
  "timeStamp": "2026-05-17T02:00:00Z"
}
{
  "timeStamp": "2026-05-17T04:00:00Z"
}
{
  "timeStamp": "2026-05-17T12:00:00Z"
}
{
  "timeStamp": "2026-05-17T14:00:00Z"
}
{
  "timeStamp": "2026-05-17T17:00:00Z"
}
{
  "timeStamp": "2026-05-18T02:00:00Z"
}
{
  "timeStamp": "2026-05-18T04:00:00Z"
}
{
  "timeStamp": "2026-05-18T09:00:00Z"
}
{
  "timeStamp": "2026-05-18T16:00:00Z"
}
{
  "timeStamp": "2026-05-18T22:00:00Z"
}

Ryota Shimizu 25 Reputation points

2026-05-28T15:22:43.6333333+00:00
Based on all of the above, my best guess is that something changed on the Azure Monitor (or capacity-metrics emission) side in mid-May 2026.

Has anyone seen the same thing, or have any information about it? Specifically:

Are you seeing intermittent gaps in Blob metrics starting around mid-May 2026 (especially in Japan East)?

Is there any known change or incident on the Azure Monitor / capacity-metrics side around 5/14 UTC that would explain this?

Any pointers or "same here" reports would be really helpful. Thanks!
Ravi Varma Mudduluru 12,625 Reputation points Microsoft External Staff Moderator

2026-05-29T23:58:41.2766667+00:00

Hello @Ryota Shimizu

At this time, there is no publicly documented Azure service incident or change that aligns with this exact timeframe. Based on available information, this appears to be related to how Blob capacity metrics are computed and emitted by background processes rather than an issue with the underlying storage data.

The metric values themselves remain accurate, but some hourly data points may not be emitted, resulting in intermittent gaps. These are interpreted as “no data” (null) rather than zero values, and such points are typically not backfilled later.

If this behavior is impacting monitoring or alerting scenarios, please check the Private message and share the requested details.

I verified in this: https://azure.status.microsoft/en-us/status and didn't find any know issue on the particular time stamp.

If the answer is helpful, please click "upvote" and kindly upvote it. If you have extra questions about this answer, please click "Comment".
Amira Bedhiafi 43,046 Reputation points MVP Volunteer Moderator

2026-06-03T07:40:04.29+00:00

@Ryota Shimizu

Because the same 17 PT1H buckets are missing for both BlobCapacity and BlobCount, and because those buckets are now several days old I will treat them as missing metric samples rather than delayed data.

I understand there is no publicly documented Azure incident or announced change matching 2026-05-14 UTC.

For monitoring and alerting, try to handle these as null or no data points and avoid interpreting them as zero capacity or zero blob count.

Ryota Shimizu 25

Thanks everyone for the help and input.

Quick update for others who may run into the same thing: the issue cleared up on its own — since June 19, 15:30 UTC the Blob Count and Blob Capacity metrics have been emitting normally again with no intermittent gaps (see attached chart, 6/16–6/22 UTC). Closing this out as resolved.

スクリーンショット 2026-06-23 9.16.54

# Since June 19, 15:30 UTC, there have been no missing data points
$ az monitor metrics list \
  --resource $resource \
  --metric BlobCapacity \
  --interval PT1H \
  --aggregation Average \
  --start-time 2026-06-19T15:30:00Z \
  --end-time 2026-06-21T15:30:00Z \
| jq '.value[].timeseries[].data[] | select(has("average")|not)'

# Before June 19, 15:30 UTC, the gaps were present.
$ az monitor metrics list \
  --resource $resource \
  --metric BlobCapacity \
  --interval PT1H \
  --aggregation Average \
  --start-time 2026-06-01T00:00:00Z \
  --end-time 2026-06-19T15:30:00Z \
| jq '.value[].timeseries[].data[] | select(has("average")|not)'
{
  "timeStamp": "2026-06-02T00:00:00Z"
}
{
  "timeStamp": "2026-06-02T03:00:00Z"
}
{
  "timeStamp": "2026-06-02T11:00:00Z"
}
{
  "timeStamp": "2026-06-02T18:00:00Z"
}
{
  "timeStamp": "2026-06-02T19:00:00Z"
}
{
  "timeStamp": "2026-06-04T13:00:00Z"
}
{
  "timeStamp": "2026-06-05T07:00:00Z"
}
{
  "timeStamp": "2026-06-05T10:00:00Z"
}
{
  "timeStamp": "2026-06-05T11:00:00Z"
}
{
  "timeStamp": "2026-06-05T18:00:00Z"
}
{
  "timeStamp": "2026-06-05T22:00:00Z"
}
{
  "timeStamp": "2026-06-05T23:00:00Z"
}
{
  "timeStamp": "2026-06-06T01:00:00Z"
}
{
  "timeStamp": "2026-06-07T17:00:00Z"
}
{
  "timeStamp": "2026-06-08T01:00:00Z"
}
{
  "timeStamp": "2026-06-08T08:00:00Z"
}
{
  "timeStamp": "2026-06-08T21:00:00Z"
}
{
  "timeStamp": "2026-06-09T03:00:00Z"
}
{
  "timeStamp": "2026-06-10T08:00:00Z"
}
{
  "timeStamp": "2026-06-10T11:00:00Z"
}
{
  "timeStamp": "2026-06-10T17:00:00Z"
}
{
  "timeStamp": "2026-06-10T21:00:00Z"
}
{
  "timeStamp": "2026-06-11T04:00:00Z"
}
{
  "timeStamp": "2026-06-11T06:00:00Z"
}
{
  "timeStamp": "2026-06-11T20:00:00Z"
}
{
  "timeStamp": "2026-06-11T23:00:00Z"
}
{
  "timeStamp": "2026-06-12T05:00:00Z"
}
{
  "timeStamp": "2026-06-13T00:00:00Z"
}
{
  "timeStamp": "2026-06-13T19:00:00Z"
}
{
  "timeStamp": "2026-06-14T01:00:00Z"
}
{
  "timeStamp": "2026-06-14T12:00:00Z"
}
{
  "timeStamp": "2026-06-14T21:00:00Z"
}
{
  "timeStamp": "2026-06-15T06:00:00Z"
}
{
  "timeStamp": "2026-06-15T18:00:00Z"
}
{
  "timeStamp": "2026-06-16T00:00:00Z"
}
{
  "timeStamp": "2026-06-16T12:00:00Z"
}
{
  "timeStamp": "2026-06-16T15:00:00Z"
}
{
  "timeStamp": "2026-06-17T00:00:00Z"
}
{
  "timeStamp": "2026-06-18T01:00:00Z"
}
{
  "timeStamp": "2026-06-18T05:00:00Z"
}
{
  "timeStamp": "2026-06-18T08:00:00Z"
}
{
  "timeStamp": "2026-06-19T05:00:00Z"
}
{
  "timeStamp": "2026-06-19T07:00:00Z"
}
{
  "timeStamp": "2026-06-19T08:00:00Z"
}
{
  "timeStamp": "2026-06-19T14:00:00Z"
}