Software Delivery in a Minute
Recovery Time
Time to restore service after a change-induced failure—definition choices and limits.
In one sentence
Recovery time (time to restore) measures how long it takes to restore service after a failure—often after a bad deployment.
Why it matters
Fast recovery limits blast radius. Slow recovery turns small defects into long outages. The metric is only comparable when start and end events are shared.
How it works
- Define failure start (alert, SEV open, error budget burn threshold).
- Define restore end (mitigation deployed, SEV closed, SLO recovered).
- Measure distributions across incidents, not only heroic best cases.
- Improve with rollback automation, feature flags, and clear ownership—not blame charts.
Example
Incident detected 14:02, bad change rolled back 14:27 → 25 minutes to restore under a rollback-based definition. Customer communications may continue longer; that is a different clock unless you say otherwise.
What this proves
Recovery time proves elapsed time between your defined failure and restore events.
What this does not prove
Fast recovery does not prove the underlying defect is fixed, or that customer trust is restored.
Sources
Last reviewed 2026-09-06. Title for citation: Software Delivery in a Minute: Recovery Time.