RTO (Recovery Time Objective) is the target maximum duration between the start of an outage and the point where the service is restored to working order.
Why it matters
RTO sets the design of your recovery process. A 4-hour RTO can be met with restoring from backups onto new servers, while a 1-minute RTO requires hot standbys and automatic failover.
It is a target, not a promise, and it includes more than technical restore time: detection, decision-making, DNS changes and verification all count. Writing the steps down and timing a drill shows whether the number is realistic.
Example
A service has an RTO of 30 minutes. The runbook allows 5 minutes to detect, 10 to start the replacement stack from scripts, 10 to restore data, and 5 to verify and switch traffic.
Common mistakes
- Counting only restore time and ignoring detection and verification.
- Choosing an RTO that the available process could never meet.
- Mixing it up with RPO, which concerns data loss.
Related
Get notified when this term updates
Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.
This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.