Context
A lifecycle rule describes when Azure may act on stored objects. It is not an immediate deletion command. A blob name can represent a current object, several previous versions and snapshots, each with its own timestamps. If the rule covers only one of those objects, storage consumption can remain even when the rule is working as configured.
This guide addresses retention behavior after a lifecycle policy is enabled. Start with an account and container you can inspect, permission to read their configuration, and an agreed business retention requirement. Do not start by shortening every retention setting to make the usage chart fall.
1. Inspect one object family
Choose a blob that should have expired and record its full container-relative name. In the portal, open its Versions and Snapshots views, including deleted entries. Record the current object's modification time separately from each previous version's creation time. A previous version is evaluated using its creation timestamp, not the date on which another write made it a previous version.
Export or read the entire lifecycle policy. Check whether its actions include the base blob, previous versions and snapshots. When versions or snapshots exist, deleting the current blob requires addressing those associated objects too. An account-level total cannot tell you which member of the object family remains.
2. Recalculate eligibility from the filter
Check the exact prefix, including the container name, capitalization and slash boundaries. A prefix intended for an archive folder can accidentally exclude an application that writes to a similarly named location. Check blob type and any blob index tag conditions. A metadata property and a blob index tag are different features; finding a value in metadata does not prove that a tag filter matches.
Calculate the threshold against the timestamp used by that specific action. Last-access-based rules also need the relevant access tracking configuration. Save this calculation alongside the policy so another operator can reproduce it. Avoid editing the rule repeatedly while waiting for a result because policy changes interrupt normal evaluation progress.
3. Account for protection and execution timing
Read the account's soft-delete settings and the container's immutability configuration. A lifecycle deletion can move eligible data into soft deletion, leaving it recoverable and billable until that retention period finishes. An immutability policy can prevent deletion altogether. These are separate explanations and need separate evidence.
Policy updates and the first execution are asynchronous. Microsoft documents that changes can take up to 24 hours to take effect and start their first run. Use timestamps rather than repeated manual refreshes to decide whether the observation window is meaningful. Large-scale processing also deserves patient, scoped verification.
Diagnostic checkpoints
| Observation | Likely boundary | Next evidence |
|---|---|---|
| Current blob remains with versions | Incomplete action coverage | Version and snapshot actions |
| Deleted entries still consume capacity | Soft-delete retention | Expiration dates |
| Only one folder is unaffected | Filter mismatch | Exact prefix and tags |
| Delete fails on protected records | Immutability | Effective retention policy |
Illustrative scenario
A hypothetical finance export is overwritten weekly. Its rule deletes current blobs after a chosen business interval but never addresses previous versions. The operator sees the current name and concludes that scheduling failed. Inspecting the version list reveals the missing policy scope. A reviewed rule can handle the permitted historical objects while preserving the required recovery window. This is an example, not a reported customer result.
Verify and maintain the retention SOP
Validate a proposed correction against a small, noncritical prefix with representative versions and snapshots. Record which objects should become eligible and when. After a complete policy observation window, compare their individual states and the later capacity trend. Acceptance requires expected retention behavior, not simply a successful policy save.
Keep the policy export, data owner's approval and verification timestamps in the retention SOP. Review new application prefixes, changes to versioning and exceptions for immutable records. Monitor storage growth by data family so ordinary version accumulation does not become a surprise bill.
Explore Clouvenix cloud cost optimization for implementation and operational handover.