Microsoft.Storage/storageAccounts: BlobCapacity/UsedCapacity publish with a highly variable, undocumented delay past the PT1H boundary
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 58/100
- Issue type
- Documentation
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- azure
- Domain
- documentation, observability-sre
Research direction
Start with the two linked supported-metrics reference pages and verify the reported hourly publication lag against the ARM Metrics REST API and metrics:getBatch observations. Document the expected or worst-case delay for BlobCapacity and UsedCapacity on both pages, with completion marked by clear guidance for distinguishing delayed from missing data.
Written by the indexing model from the issue text.
Description
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.
- Dominant language
- PowerShell
- Stars
- 1.2k
- Forks
- 493
- PR merge metrics
- No merged PRs in 30d
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from microsoft/AzureMonitorCommunity
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
-
Difficulty 5/5 Over a week Newbie friendliness 20/100
-
Difficulty 4/5 3-5 days Newbie friendliness 10/100
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
All issues in microsoft/AzureMonitorCommunity
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
agilepathway/label-checker#640 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
BasedHardware/omi#15662 · 1 comment ·
-
documentation help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
-
documentation good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
amponce/archive-movie-browser#167 ·
-
user-reported
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Kong/developer.konghq.com#7316 ·