ACR StorageUsed remains at 91.8 GiB / 411.63 GiB after successful image purge, far above reachable manifest data

Question

ACR StorageUsed remains at 91.8 GiB / 411.63 GiB after successful image purge, far above reachable manifest data

Christopher Trybus 0

We are seeing a substantial and apparently stale Azure Container Registry

storage usage/accounting discrepancy in UK South.

Subscription:

0989c189-4f1d-449a-841f-3a974a5b72e8

Affected registries:

timelineuksdevacr01 Resource group: timeline-dev-rg SKU: Basic Reported StorageUsed/show-usage: 98,566,384,671 bytes (91.80 GiB)
timelineuksprodacr Resource group: timeline-prod-rg SKU: Standard Reported StorageUsed/show-usage: 441,983,717,571 bytes (411.63 GiB)

Both registries contain only two repositories:

timeline-api
timeline-worker

On 10 August 2026 we successfully ran an ACR purge of all untagged

manifests.

Successful ACR Task run IDs:

Dev actual purge: dbj, completed 2026-08-10 13:16:18 UTC
Prod actual purge: db2a, completed 2026-08-10 13:16:35 UTC

Current state after the purge:

Dev:

timeline-api: 2 tagged manifests, 0 untagged, approximately 12.73 GiB aggregate imageSize
timeline-worker: 2 tagged manifests, 0 untagged, approximately 12.73 GiB aggregate imageSize
The repositories reference the same image digests/layers.

Prod:

timeline-api: 5 tagged manifests, 0 untagged, approximately 32.92 GiB aggregate imageSize
timeline-worker: 5 tagged manifests, 0 untagged, approximately 32.92 GiB aggregate imageSize
The repositories reference the same image digests/layers.

Despite successful manifest deletion, az acr show-usage and the Azure

Monitor StorageUsed metric remain unchanged at 91.80 GiB and 411.63 GiB.

Even if shared image data were counted separately for both repositories,

the reachable manifest data is substantially below the reported usage.

There are no other repositories. Soft delete and the native retention

policy are disabled.

The dev registry is particularly concerning because its reported usage

has remained at approximately 91.8 GiB for an extended period, rather

than this only being a short delay following today's purge.

Please:

Inspect the backend ACR storage accounting and garbage-collection state for orphaned/unreferenced blobs.
Confirm the current billable storage quantity for each registry, independently of the delayed StorageUsed metric.
Confirm whether additional-storage charges stopped when the manifests were deleted.
Force or repair garbage collection/storage accounting if it is stuck.
Explain the difference between reachable manifest/layer data and the reported StorageUsed values.
Review and credit any additional-storage charges caused by incorrectly retained or incorrectly billed deleted image data.

Microsoft documentation states that billing for deleted image data stops

immediately, although physical reclamation and the StorageUsed metric are

asynchronous. Please confirm that this is occurring for these resources.

Dev registry: DevRegistryCosts

Prod Registry:

ProdRegistryCosts

task_logs_timelineuksdevacr01.txt

task_logs_timelineuksprodacr.txt

usage_timelineuksdevacr01.txt

Saraswathi Devadula 16,040 Reputation points Microsoft External Staff Moderator

2026-08-10T16:33:46.1266667+00:00
Hello Christopher Trybus

Hey! It sounds like you ran an ACR purge of untagged manifests, and your registry still shows a large, seemingly stale StorageUsedvalue in az acr show-usage / the Azure Monitor storage metric—well above what you believe the reachable manifests/layers should account for.

Based on the provided docs, the most common reason for “storage usage doesn’t go down after delete is layer/reference accounting (shared layers and still-referenced data), plus the fact that billing stops immediately but physical reclamation / usage metrics are asynchronous.

1) “Reachable manifests” vs what StorageUsed still counts:

ACR stores layers and **manifestsseparately. Even if you delete manifests/tags you expect to remove, layers may remain if they are still referenced by any remaining manifest in the registry.

So, StorageUsed may remain higher than reachable manifest data because:

Shared underlying layers are stored once but are only deletable when no manifest references them anymore.

If any manifest in the registry (including ones you didn’t delete or still-tagged/or still referenced) references those layers, ACR keeps the layers.

Microsoft explicitly notes:

If underlying layers are still referenced by other images, registry quota usage may go down more slowly than expected.

After you delete image data, ACR stops billing you immediately but recovers the associated storage space using an asynchronous process, and it takes time for the registry to clean up layers and show updated usage.

Ref: Azure Container Registry | Microsoft Learn
https://learn.microsoft.com/en-us/azure/container-registry/container-registry-delete?wt.mc_id=knowledgesearch_inproduct_azure-cxp-community-insider
Troubleshoot Azure Container Registry delete operation issues - Azure | Microsoft Learn

2) Purge/batch delete is asynchronous in how StorageUsed updates:

Even when the purge succeeds, the metric/usage views can take time to reflect the cleanup. The docs call out that:

Billing stops right away,

storage recovery and updated metrics are eventually consistent/ asynchronous.

So, a still unchanged after purge situation can happen even with correct deletion—especially for larger registries or when cleanup/GC is still running.

3) In some purge workflows, deleting manifests/tags doesn’t immediately remove all data you expect:

The purge tooling can be nuanced. The provided doc excerpt for purge explains that automated purge can remove tag references and optionally untagged manifests, but it doesn’t always mean all underlying layer data disappears instantly that still depends on whether the layers remain referenced.

A) Confirm whether layers are still referenced by remaining tagged content:

From the docs, storage doesn’t drop if layers remain referenced by other manifests. In other words, even if you have “only two repositories,” that doesn’t guarantee that no manifests remain referencing the large layer set.

Practical approach (conceptual, since you already know the end state conceptually):

Verify the current set of tagged manifests and ensure there truly are no other tag references pointing at the same digests/layers.

Validate that any “old/orphaned” manifests truly have no tags and were removed (or that the layers aren’t still referenced).

(Your observation that both repos reference the same digests/layers strongly suggests shared layers should still only count once physically, but logically the metric may still be waiting on GC/refs to be fully cleared.)

B) Compare billing vs StorageUsed` metric:

Since billing should stop immediately after deletion but metrics update asynchronously, the docs recommend treating StorageUsed as lagging.

If billing/extra charges stopped while StorageUsed stayed high, that strongly suggests the cleanup is still pending (async reclamation), not that the data is still billable.

Follow-up questions:

To properly explain what’s happening, we’d need a couple extra details:

For each registry, what is the exact storage metric source you’re looking at (portal chart vs az acr show-usage only)?

After the purge, when you run az acr show-usage --name <registry>, does the usage ever change at all (even by small amounts), or is it completely flat for days?

Do you have any retention/soft delete policy enabled now (you mentioned disabled—confirm via CLI/portal)?

Does each repo currently show only the expected number of tagged digests (and no additional tags)?

Were there any recent pushes or concurrent ACR tasks that might have reintroduced tags/manifest references while or after purge?

Can you share outputs of: az acr manifest list-metadata --name <repo> --registry <acr> ## for detecting any lingering untagged/orphaned manifests
Christopher Trybus 0 Reputation points

2026-08-10T16:43:00.33+00:00
Thanks. We have now checked the requested items.

Metric source

Both az acr show-usage and the Azure Monitor StorageUsed metric show the

same values:

timelineuksdevacr01: 98,566,377,299 bytes (91.80 GiB)

timelineuksprodacr: 441,983,699,141 bytes (411.63 GiB)

The Azure Monitor metric remains at the same values after the purge.

Policies

Both registries currently have:

Retention policy: disabled

Soft-delete policy: disabled

Current manifests

timelineuksdevacr01:

timeline-api: 2 tagged manifests, 0 untagged

timeline-worker: 2 tagged manifests, 0 untagged

timelineuksprodacr:

timeline-api: 5 tagged manifests, 0 untagged

timeline-worker: 5 tagged manifests, 0 untagged

The API and worker repositories contain the same manifest digest sets and

there are no other repositories.

Referenced layer calculation

We fetched each retained Docker manifest and calculated the union of all

referenced layer digests:

Dev: 28 unique referenced layers, totaling approximately 12.68 GiB

Prod: 64 unique referenced layers, totaling approximately 32.75 GiB

Because timeline-api and timeline-worker reference the same digest sets,

the second repository does not introduce another distinct set of layers.

This leaves approximately:

Dev: 79.12 GiB not explained by reachable layers

Prod: 378.88 GiB not explained by reachable layers

Even if the repositories were counted separately, their combined virtual

image sizes would only be approximately 25.36 GiB and 65.5 GiB.

Purge and concurrent activity

The actual purge tasks succeeded:

Dev: run dbj, completed 2026-08-10 13:16:18 UTC

Prod: run db2a, completed 2026-08-10 13:16:35 UTC

There were no image pushes after the purge. The newest production image

was created at approximately 11:15 UTC, around two hours before the purge.

Usage decreased by only a few kilobytes following deletion:

Dev: reduction of 7,372 bytes

Prod: reduction of 18,430 bytes

This appears consistent with manifest metadata being removed, but not the

large unreferenced image layers.

The dev StorageUsed value has also been flat at approximately 91.8 GiB

since at least 10 July, so this does not appear to be solely a short delay

following the latest purge.

We are checking the daily Container Registry Data Stored billing meter

after the normal Cost Management reporting delay.

Can you please clarify:

What is the expected maximum duration for ACR asynchronous layer reclamation?

Can Microsoft inspect the registry's backend reference counts and garbage-collection state for the unexplained 79.12 GiB and 378.88 GiB?

Is there a supported way to obtain the actual billable byte quantity, independently of StorageUsed?

If backend inspection is not possible through Q&A, should this now be handled through an Azure technical support request?

2 answers

Your answer

Answer 1

Hi ,

Thanks for reaching out to Microsoft Q&A.

The following items are not visible to customers or community moderators:

Backend garbage collection status
Orphaned blob inventory
internal storage-accounting state
Current billable byte count used by microsoft's billing systems
Eligibility for credits or refunds

Only Microsoft support and the ACR engineering team can validate those items. The production registry may simply be experiencing normal storage accounting lag after the purge operation. However, the development registry is more notable because you indicate that:

Only 2 repositories exist.
No untagged manifests remain.
Reported usage has remained around 91.8 GiB for an extended period, rather than only after the recent purge.

If that history is accurate, ms support should investigate whether:

Storage-accounting reconciliation has completed successfully.
Orphaned blobs remain in the registry backend.
The reported StorageUsed metric is out of sync with the current registry contents.

Recommended request to Microsoft Support. I would recommend asking Microsoft to confirm:

The current billable storage amount for each registry.
Whether deleted image data has already been excluded from billing.
Whether any orphaned or unreferenced blobs remain.
Whether garbage collection and storage-accounting reconciliation have completed successfully.
Whether the reported StorageUsed values accurately reflect the registry's current state.

One suggested change to the original request: Instead of requesting that Microsoft "force garbage collection", consider asking them to:

Investigate whether garbage collection or storage accounting reconciliation is delayed or stalled and perform any corrective action required. This aligns better with ACR's platform-managed architecture, where garbage collection is not a customer-controlled operation.

Please 'Upvote'(Thumbs-up) and 'Accept' as answer if the reply was helpful. This will be benefitting other community members who face the same issue.

Vinodh247-1375 44,636 Reputation points Volunteer Moderator

2026-08-25T16:08:09.1133333+00:00

Christopher Trybus

Please confirm if you had a chance to try any of the suggestions provided for your question.

Please 'Upvote'(Thumbs-up) and 'Accept' as answer if the reply was helpful.

If in case you have any resolution please share the same here with the community as it can be helpful to others. Else, please respond with more details and we will try to see if we can help further.

Answer 2

Saraswathi Devadula 16,040 Microsoft External Staff Moderator

Hello Christopher Trybus

Problem Scope: ACR storage consumption remained significantly higher than expected after performing a purge operation.

Cause: The registry storage usage was not reconciled following the purge operation, resulting in storage values that did not accurately reflect the actual registry content.

Resolution: The Azure Container Registry engineering team manually reconciled the registry storage usage, correcting the reported values to reflect the actual storage usage.

0 comments