Kubernetes 1.37 PVC Last-Used Tracking: Find Idle Storage Safely

PersistentVolumeClaims often survive the workloads that created them. That protects data, but it also leaves storage bills full of claims nobody can confidently delete. Kubernetes 1.37 adds a native signal that makes the investigation easier: an Unused condition on PVC status.

The signal answers whether a non-terminal Pod currently references a claim. It does not prove that the data is disposable.

What Changed in Kubernetes 1.37

The PersistentVolumeClaimUnusedSinceTime feature graduated to beta and is enabled by default. The existing PVC protection controller now maintains an Unused condition:

The condition's lastTransitionTime records when the controller observed the transition. That gives administrators an approximate “unused since” timestamp without maintaining a separate Pod-to-PVC inventory service.

Inspect One Claim

On a Kubernetes 1.37 cluster, inspect the condition with:

kubectl get pvc app-data -n production \
  -o jsonpath='{.status.conditions[?(@.type=="Unused")]}' | jq .

An idle claim resembles:

{
  "lastTransitionTime": "2026-08-10T14:22:00Z",
  "message": "No pods are currently referencing this PVC",
  "reason": "NoPodsUsingPVC",
  "status": "True",
  "type": "Unused"
}

The timestamp is when the controller observed that no qualifying Pods referenced the claim. It is not a storage-array access timestamp and does not track reads made outside Kubernetes.

Find Claims Idle for More Than 30 Days

This query lists PVCs whose Unused condition has remained true for more than 30 days:

kubectl get pvc -A -o json | jq -r '
  .items[]
  | select(.status.conditions[]?
      | select(.type == "Unused" and .status == "True"))
  | (.status.conditions[] | select(.type == "Unused")) as $condition
  | select((now - ($condition.lastTransitionTime | fromdateiso8601)) > (30 * 86400))
  | "\(.metadata.namespace)/\(.metadata.name)\t\($condition.lastTransitionTime)"
'

Use the output as a review queue, not a deletion list.

Understand the Edge Cases

A pending Pod counts as using the PVC, even when it cannot schedule. Kubernetes interprets the reference as intent to use the claim. Investigate the pending Pod rather than overriding the signal.

Pods in Succeeded or Failed phase do not count. That is helpful for completed Jobs, but their output may still need retention. The controller cannot know whether a legal, backup, analytics, or recovery process needs the data later.

For a shared claim, Unused=True appears only after the last non-terminal Pod stops referencing it. The signal operates at the claim level, not at the file or application-owner level.

Build a Safe Cleanup Workflow

Use multiple stages:

1. Discover claims with Unused=True beyond an agreed age.
2. Exclude protected namespaces and stateful production tiers.
3. Identify the owner from labels, annotations, or inventory.
4. Check StatefulSets, Helm releases, GitOps repositories, backup policy, and restore requirements.
5. Snapshot or back up the volume when policy requires it.
6. Mark the PVC as a cleanup candidate and wait through a review window.
7. Delete only after owner approval or a documented non-production policy.

For example, add an annotation before deletion:

kubectl annotate pvc app-data -n staging \
  cleanup.devopsboys.com/candidate-since=2026-09-25

An admission policy can prevent direct deletion of protected claims unless a separate approval annotation is present.

Do Not Confuse Reclaim Policy with PVC Usage

The PersistentVolume reclaim policy controls what happens to the underlying volume after its claim is deleted. Retain leaves the storage asset for manual recovery; Delete may remove it through the storage provisioner.

Before deleting a claim, inspect both objects:

kubectl get pvc app-data -n staging -o wide
kubectl get pv PV_NAME -o jsonpath='{.spec.persistentVolumeReclaimPolicy}{"\n"}'

With a Delete policy, a mistaken PVC cleanup may become permanent data loss. Our PV and PVC explainer covers the lifecycle relationship.

Turn the Signal into FinOps Evidence

Export the condition and timestamp into your inventory or metrics pipeline. Useful views include idle capacity by namespace, storage class, team, environment, and age bucket. Combine provisioned GiB with cloud price data to estimate savings.

Avoid measuring success only by deleted volume count. Track recovered cost, restore requests after deletion, claims without owners, and candidates that repeatedly return to use. A high restore rate means the policy is too aggressive.

For broader savings work, see the Kubernetes cost optimization guide.

Practical Rule

Treat Unused=True as strong evidence that Kubernetes has no current Pod reference. Require separate evidence that the organization no longer needs the data.

Kubernetes 1.37 removes much of the inventory work. It intentionally leaves the deletion decision with you.

Sources

• Kubernetes: Tracking when a PVC was last used
• Kubernetes: Persistent Volumes
• Kubernetes: Storage object in use protection