Kubernetes v1.37: Tracking When a PersistentVolumeClaim Was Last Used (Beta)

Storage costs in Kubernetes can quietly spiral out of control. You provision a PersistentVolumeClaim (PVC) for a service, the service gets updated or removed, but the storage claim lingers—still incurring charges, still consuming quota. Until now, figuring out which PVCs were actually in use meant writing custom scripts to cross-reference pods with their volume mounts. Kubernetes v1.37 changes this with the promotion of PersistentVolumeClaimUnusedSinceTime to Beta, a feature that automatically tracks whether any running pod is currently using a PVC.

Here’s how it works: the PVC protection controller now automatically adds an Unused condition to each PersistentVolumeClaim, indicating whether it’s actively mounted by a pod. The feature operates at the cluster level without requiring any custom tooling or external monitoring systems. When you inspect a PVC’s status, you’ll see a condition that tells you definitively whether the claim is referenced by any running workload. If a pod uses the PVC, the condition reflects that. If no pod references it—whether it was recently unmounted or never attached—the condition captures that too. Since this is now in Beta and enabled by default in v1.37, most clusters upgrading will gain this visibility automatically.

The practical benefit is significant for cost optimization and cluster hygiene. In organizations running hundreds of microservices, identifying orphaned storage has been tedious and error-prone. A typical workflow might involve: provisioning a PVC for a staging environment, the environment being torn down but the PVC remaining, then months later, someone finally notices the cost. With the Unused condition, you can now write simple scripts or use kubectl queries to find unused claims and make informed deletion decisions. Similarly, platform teams can implement automated cleanup policies—for example, alerting or removing PVCs that haven’t been used in 30 days. This moves storage management from a manual, reactive process to something observable and automatable.

If you’re managing Kubernetes infrastructure, this is worth testing in a non-production cluster first to understand the behavior and integrate it into your cost management workflows. For those using EKS, GKE, or other managed Kubernetes services, check your provider’s upgrade timeline to see when v1.37 becomes available. The feature removes a long-standing blind spot in Kubernetes resource visibility, letting you focus on what actually matters: running efficient, cost-effective clusters.