{"head":{"title":"What Is RTO (Recovery Time Objective)? | OceanLab","description":"RTO is how long a system can be down after a failure before it seriously harms the business. How it pairs with RPO, an example and common mistakes.","canonical":"https://oceanlab.in/glossary/rto"},"crumbs":[{"name":"Home","path":"/"},{"name":"Glossary","path":"/glossary"},{"name":"RTO","path":"/glossary/rto"}],"slug":"rto","term":"RTO (recovery time objective)","aka":["recovery time objective"],"category":"Reliability","short":"How long a system can stay down after a failure before the outage seriously harms the business.","body":[["NIST defines RTO as the overall length of time a system's components can be in the recovery phase before negatively affecting the organisation's mission. Put simply: the deadline for getting the service back."],["RTO is about time; ",{"href":"/glossary/rpo","text":"RPO"}," is about data. A system can have a short RTO and a long RPO, or the other way round. A one-hour RTO usually needs automated failover or a rehearsed restore; a three-day RTO can rely on rebuilding from backups."]],"why":["Every minute of downtime has a cost: lost sales, staff who cannot work, missed ",{"href":"/glossary/sla","text":"SLA"}," credits. A clear RTO tells the team how much to invest in redundancy and how fast the recovery steps must be."],"example":["A clinic's booking system has an RTO of two hours during opening hours. The team keeps a standby database in another region and practises the switch every quarter. The internal reporting tool has an RTO of two days and is simply restored from backup."],"inBuild":["RTO shapes hosting, the deploy and rollback setup, and the runbook that goes into the handover pack at the end of a build."],"mistakes":[["Choosing an RTO the architecture cannot meet, and finding out during an outage."],["Counting only the restore time, not the time to notice, decide and check the data."],["No written runbook, so recovery depends on one person being awake."]],"related":[{"href":"/glossary/rpo","label":"RPO (recovery point objective)","detail":"The point in time to which data must be recoverable after an outage: in practice, how much recent data you can afford to lose."},{"href":"/glossary/uptime","label":"Uptime","detail":"The share of time a service is working and reachable, usually written as a percentage such as 99.9%."},{"href":"/glossary/sla","label":"SLA (service level agreement)","detail":"A contract that promises a level of service, such as uptime or support response time, and says what happens if it is missed."},{"href":"/glossary/slo","label":"SLO (service level objective)","detail":"An internal reliability target for a service, such as 99.9% of requests succeeding, measured by a service level indicator (SLI)."}],"tools":[],"links":[{"href":"/software","label":"Software by industry","detail":"Systems we build per industry, with guides and tools."},{"href":"/compliance/soc-2","label":"SOC 2 guide","detail":"The controls behind a SOC 2 report."}],"sources":[{"title":"NIST CSRC glossary: recovery time objective","url":"https://csrc.nist.gov/glossary/term/recovery_time_objective","checkedAt":"2026-10-25"}],"legal":false,"updatedAt":"2026-10-25"}