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.
यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.