Lifecycle
Time limits and owner attestation for short-lived resources — turning "nobody will delete it" into a question with a deadline and a named owner.
At a glance
| Route | /lifecycle |
| Section | Optimization |
| Page permission | policies |
What it is
Lifecycle attaches a time-to-live (TTL) and an owner to resources that were only ever meant to exist for a while. When the TTL expires, the owner is asked to confirm the resource is still needed. Unclaimed resources are queued for an approval-gated stop.
What a TTL is
A time-to-live is simply an expiry date attached to something. A test cluster spun up for a two-week experiment gets a two-week TTL. When that date passes, the product asks about it instead of letting it run silently for another year.
Who it is for
Platform teams whose estate accumulates test clusters, proof-of-concept databases, and forgotten environments faster than anyone deletes them.
How it works
Nothing is deleted on a timer
This is the most important property of the module.
Expiry raises a question, not a deletion
When a TTL expires, the product raises an attestation request to the recorded owner — it does not delete anything.
Only after the attestation goes unanswered does the resource enter the stop queue. And even then, the stop is an approval-gated action that appears in Approvals like any other change.
Nothing is deleted on a timer alone. There are two human checkpoints before anything stops.
Features
- TTL set at creation, or applied automatically by rule
- Owner recorded against each short-lived resource
- Attestation request on expiry rather than deletion
- Stop queue for unclaimed resources
- Approval-gated stop, surfaced in the normal Approvals flow
- Full audit trail of who attested to what, and when
How to use it
Start with non-production environments
Test clusters and proof-of-concept databases are where TTLs are least controversial and the waste is largest.
Make sure ownership is accurate first
An attestation request sent to the wrong person gets ignored, and the resource ends up in the stop queue for the wrong reason. See Ownership.
Apply TTLs by rule where you can
Setting them by hand at creation only works if every engineer remembers. A rule that applies a default TTL to anything tagged as an experiment works whether they remember or not.
Watch the first attestation cycle closely
You are looking for requests going to the right people and being answered. A high ignore rate usually means the owner data is wrong, not that the resources are abandoned.
Approve stops deliberately at first
Until you trust the attestation loop, treat the stop queue as a review list rather than a formality.
Why it matters
It is an ownership problem, not a detection problem
Most idle-resource waste is not hard to find. Everyone knows the cluster is idle.
It persists because nobody is willing to delete something they did not create — the downside of deleting something that turns out to matter is far worse than the cost of leaving it running.
Lifecycle turns that standoff into a question, with a deadline and a named owner. That is a social fix to a social problem, not a technical one.
Connects to
- Depends on Ownership for the attestation recipient
- Stops route through Approvals
- Complements Resource Parking — parking schedules recurring downtime, Lifecycle ends things that should no longer exist
- Findings appear in Opportunity Queue
- Recorded in Audit Logs
Opportunity Queue
The cross-cloud triage surface — every detection lands here as a costed, scored finding with SLA tracking, compliance mapping, and evidence export.
Resource Parking
Scheduled shutdown — AutoStopping, off-hours parking, hibernation, and scale-to-zero in one control plane, with unsafe-schedule detection.