Usually one of three reasons: you untagged rather than deleted, the layers are shared with images that remain, or the registry reclaims space later. Azure documents all three. Only layers unique to a deleted image are removed, and cleanup of storage is asynchronous.
Reason one: untagging frees nothing
Removing a tag leaves the manifest and its layers in place. Azure's documentation says no space is freed when you untag, because only the tag reference is deleted. If your cleanup step removes tags only, the registry stays full. See untag, delete by tag or delete by digest.
Reason two: layers are shared
Images are built from layers, and many images share the same base layers. When you delete an image, only layers not referenced by other images are removed. Azure says deleting by tag recovers space used by unique layers, and shared layer data is not deleted.
This explains an odd effect: deleting ten old images may free little if they all share a large base with the images you keep. The base layer stays until nothing references it.
| What you delete | What is removed |
|---|---|
| A tag reference only | The tag |
| An image by tag or digest | Manifest, its tags, layers unique to it |
| A whole repository | All images in it and their unique layers |
Reason three: reclamation is asynchronous
Azure notes that after you delete image data, billing for the associated storage stops immediately, but the registry recovers the space with an asynchronous process, so it takes time before cleanup shows in usage. Other registries may behave differently. Self hosted registries often need an explicit garbage collection run, which is why our post on how Docker registry garbage collection works is worth reading if you run your own.
Reason four: you deleted the wrong things
If the images you removed are small and the big ones remain, usage barely moves. Look at which repositories use the most space, not just which have the most tags.
A troubleshooting order
- Confirm the operation was a delete, not an untag.
- Check whether the images share layers with ones you kept.
- Wait for the asynchronous cleanup, then recheck.
- For a self hosted registry, check whether garbage collection has run.
- Find the largest repositories and focus there.
Why this matters for security
Space is a side effect. The security point is inventory: images you no longer need should not remain pullable. Measure success by the number of repositories and tags you can no longer pull, not by storage numbers. See is deleting old images a security control.
Set expectations with your team
If a cleanup is meant to cut usage, tell stakeholders that the number may not drop for a while and may drop less than expected. Pair the usage figure with a count of repositories and tags removed, which moves immediately and is closer to the real security goal.
Quick check
How long until space is reclaimed?
Azure describes it as asynchronous without a fixed time. Recheck later, and for self hosted registries run garbage collection.
Does deleting a shared base layer image free the base?
No. Shared layers stay until no remaining image references them.
Sources
Last reviewed: 19 October 2026.
