Microsoft.Storage/storageAccounts: BlobCapacity/UsedCapacity publish with a highly variable, undocumented delay past the PT1H boundary

[marcinsiennicki95]

Summary

BlobCapacity and UsedCapacity (Capacity category, Microsoft.Storage/storageAccounts) are documented
with Time Grains PT1H, PT6H, PT12H, P1D, but nothing in the docs says how long after an hour boundary the
bucket for that hour actually becomes available.

Evidence

Measured directly across several storage accounts, polling every ~5 minutes across two hour boundaries via
both the ARM metrics API and the batch metrics API:

• Account A: the new hourly bucket was already populated ~6 minutes after the hour.
• Account B: 70+ minutes after the hour boundary, the API was still returning the previous hour's bucket
  — the new one hadn't appeared yet (we stopped watching before it did).
• Account C: same lagging pattern as account B, still on the stale hour's value at the same poll.

This was identical between the ARM metrics endpoint and the batch metrics endpoint (metrics:getBatch), so
it isn't an artifact of one API path — same accounts, same lag, on both.

Question / Ask

Could the supported-metrics reference pages for
Microsoft.Storage/storageAccounts
and
Microsoft.Storage/storageAccounts/blobServices
document the expected (or worst-case) publication delay for these Capacity metrics, so consumers of the
Metrics API know how long to wait before treating a missing/stale hourly bucket as "not published yet" as
opposed to "actually missing"? Right now the delay is unbounded and appears to vary per account, with no way
to anticipate it from the documented Time Grain alone.

Environment

Queried directly via the ARM Metrics REST API and the batch metrics API (metrics:getBatch), not through
any client library.