An unused Kubernetes volume isn't permission to delete it.

A storage report says a volume is unused. That doesn't tell you whether the data is disposable. The useful next step is to find its owner and purpose, not wire the report straight into a delete command.

For software companies running busy clusters, platform teams and compute operators, this is a capacity problem with a recovery risk attached. Storage can stay allocated after the work stops. Reclaiming it can help, but only when the team knows what it's giving up.

What the new signal actually tells you

Kubernetes' September 21, 2026 post explains PVC last-used tracking, promoted to beta and enabled by default in v1.37. The PersistentVolumeClaimUnusedSinceTime feature adds an Unused condition to storage claims. Unused=True means no non-terminal Pod references the claim. Pending Pods count as users; Pods in Succeeded or Failed phases don't.

That's a reference-based signal, not a last-read or last-write meter. An unschedulable Pod can keep a claim marked in use. A finished batch job can leave a claim marked unused even though its output still matters to the business. Use the condition to narrow an investigation, not decide the value of the contents.

Check whether the observation is still current

The design proposal, KEP-5541, draws two important boundaries. Disabling the feature leaves existing conditions stored but stops updating them. And lastTransitionTime describes the controller's observation, not the exact time a volume was unmounted by the underlying infrastructure. The design doesn't include automatic deletion or cleanup recommendations.

Our recommendation is to record the cluster version, feature configuration and observation time with each review. Check controller health before trusting the list. Treat missing conditions or observations from a disabled feature as unresolved, not as proof that storage is free to remove. A dated observation is useful evidence; it isn't permanent permission.

Follow the claim through to the storage asset

The Persistent Volumes documentation explains why this matters. For supported volume plugins, a Delete reclaim policy removes the PersistentVolume and its backing storage asset. Dynamically provisioned volumes inherit their StorageClass reclaim policy, which defaults to Delete. Retain leaves the data and manual reclamation work behind.

Before approving a change, inspect the actual claim, bound volume and provider resource together. Don't infer the result from a dashboard label or the name of a storage class. If the owner expects the data to remain available, the proposed action needs to account for that expectation explicitly.

Give every candidate an owner and a decision

We'd make the first output a review queue. The following is a proposed operating record, not a Kubernetes requirement or a deletion procedure. It gives the application owner and storage operator something concrete to approve, reject or investigate.

• Identity: cluster, namespace, claim, bound volume and backing storage resource. Include the observed condition and when it was checked.
• Purpose: which application or dataset owns it, whether work is paused or finished, and who can decide its future use.
• Retention: the existing retention requirement, any unresolved hold, and the person responsible for confirming it.
• Recovery: what must remain recoverable, which dependencies are required, and where the relevant restore-test evidence can be found. A backup job's success alone doesn't answer those questions.
• Action: keep, investigate or propose reclamation. Record approval, the responsible operator and the expected effect before a destructive change.

A candidate list isn't a savings report

Keep four totals separate: storage identified for review, storage approved for reclamation, changes completed, and the capacity or billing impact actually observed. These are different stages of the work. Adding up the first column and calling it savings hides every unresolved dependency in between.

This is where a small operating improvement can be more valuable than another dashboard: the observation reaches someone who can make the decision, the action has a responsible owner, and the result is checked. The goal is useful capacity without a preventable recovery problem, not the largest possible cleanup number.

Start with the recovery question you can't answer

If the blocker is unclear recovery ownership or missing instructions, bring that question to Valen Systems. We can discuss the environment and agree a scope. The fixed-price Backup Recovery Runbook is a smaller starting point: written recovery steps, dependencies and a restore-test checklist for one host and one existing backup system, using the evidence you supply. It doesn't include live restoration, a cluster-wide storage audit or permission to delete data.

Sources

1. Kubernetes: Tracking When a PersistentVolumeClaim Was Last Used (Beta)Source published September 21, 2026. Retrieved September 23, 2026.
2. Kubernetes KEP-5541: Report Last Used Time on a PVCPublication date not stated. Retrieved September 23, 2026.
3. Kubernetes Persistent Volumes: ReclaimingPublication date not stated. Retrieved September 23, 2026.