Kubernetes 1.37 promotes PersistentVolumeClaim (PVC) last-used tracking to Beta. The PersistentVolumeClaimUnusedSinceTime feature reports when a PVC was last used in pvc.Status, giving administrators another signal for investigating storage that may no longer be needed.
That signal is useful for inventory and cost-management workflows, particularly in large clusters with many claims. It is not, by itself, proof that a PVC is safe to delete. Teams still need to verify workload ownership, retention requirements, backups, and recovery procedures before removing storage.
What changed in Kubernetes 1.37
The feature was Alpha in Kubernetes 1.36 and is listed as Beta in Kubernetes 1.37. The Kubernetes feature-gate reference lists PersistentVolumeClaimUnusedSinceTime as enabled by default in v1.37.
The related Kubernetes enhancement proposal describes the purpose of the feature: exposing the last-used time for a PVC so operators can identify claims that are potentially unused. In practical terms, Kubernetes can provide usage-related metadata that can support storage reviews instead of requiring every organization to infer usage through separate processes.
Beta status means the feature is further along than its v1.36 Alpha phase, but teams should still confirm how it behaves in their own Kubernetes environment. The available documentation establishes the feature’s maturity and default setting, but it does not document every Pod-transition scenario or every detail of the status schema.
Why last-used information matters
PVC inventories often contain claims created for temporary environments, completed projects, old application versions, or workloads that have been moved elsewhere. Without usage information, an administrator may have to compare claims with workload configuration and historical operational records before deciding which storage deserves review.
Last-used metadata can make that investigation more targeted. A claim that has not been used recently may be a candidate for human review, while a recently used claim may need to remain in service. This can help platform teams organize storage inventories and investigate opportunities to reduce unnecessary storage consumption.
However, “not recently used” and “safe to delete” are different decisions. A PVC may be retained intentionally for recovery, compliance, a scheduled workload, or a future deployment. The feature supplies an operational data point; it does not define an automatic deletion policy.
Used carefully, the metadata can help teams rank claims for review, compare that signal with known workload and retention context, and document why a claim remains or is removed.
What administrators need to know about configuration
Kubernetes feature gates use the --feature-gates flag with comma-separated key=value pairs. The feature-gate documentation also notes that each Kubernetes component supports only gates relevant to its functions.
Because the feature is listed as enabled by default in v1.37, many v1.37 environments may not need an explicit setting. Administrators should nevertheless check the cluster version and effective configuration rather than assuming that every deployment exposes identical behavior. The supplied Kubernetes documentation does not identify which specific components must be configured for this feature.
The documented evidence confirms that the value is reported in pvc.Status, but it does not establish the exact status-field syntax, timestamp format, or update timing. Automation should therefore be built against the API schema and behavior available in the target cluster, not against assumptions about undocumented field details.
Implications for developers and platform teams
- Inventory tooling: PVC review tools can use the reported status information as one input when finding claims that may be unused.
- Operational review: Teams can add last-use information to storage investigation processes instead of relying only on workload inference.
- Cleanup automation: Automated deletion should not be based only on a last-used value. Ownership, workload state, retention rules, backups, and recovery testing need independent checks.
- Cluster portability: Workflows should verify the Kubernetes version and feature-gate state before assuming the metadata is available.
The feature may be especially relevant to organizations operating multiple namespaces or large clusters, where manually reviewing every claim is costly. Even there, the output should be treated as a prioritization signal rather than an authorization to remove data.
What you should do
- Confirm that the target cluster runs Kubernetes v1.37 or another version whose feature availability has been separately established.
- Check the cluster’s feature-gate configuration and confirm whether
PersistentVolumeClaimUnusedSinceTimeis enabled. - Inspect the PVC status information available in that environment and validate its schema before building dashboards or automation.
- Use the information to create an investigation queue for potentially unused claims, not an unconditional deletion list.
- Before any cleanup, verify PVC ownership, active and expected workloads, retention requirements, backups, and recovery procedures.
Teams should also document their own approval and rollback process. Kubernetes’ feature documentation supports identifying potentially unused claims, but the supplied sources do not define a universally safe storage-deletion workflow.
Availability and remaining limits
PersistentVolumeClaimUnusedSinceTime is identified as Beta in Kubernetes v1.37 and is listed with a default value of true in the v1.37 feature-gate reference. The verified documentation establishes Alpha availability in v1.36 and Beta status in v1.37, but it does not establish availability in other versions or across specific managed Kubernetes providers.
Details about multiple Pods, pending or terminated Pods, exact update transitions, and officially supported command-line or jq examples are not established by the available documentation. Those behaviors should be confirmed from the API and cluster documentation before they become assumptions in production automation.
For now, the most defensible use of the feature is as part of a cautious storage-inventory and review process. It can improve visibility into PVC usage, while the decision to retain or remove data remains an operational responsibility.
