Home / Knowledge hub / Recovery time objective
Knowledge hub
Recovery time objective
The longest outage you can accept before a system must be back.
What it means
The recovery time objective, or RTO, is the target for how quickly a system must be working again after an outage. If the RTO for your checkout service is four hours, the plan and the tools must be able to restore it within four hours of the failure.
It is a business decision before it is a technical one. It comes from asking how long the company can go without this service before the damage becomes unacceptable, then checking whether the recovery design can reach that number. It is one half of a pair, alongside the recovery point objective.
Why it matters
Setting an RTO forces a trade-off into the open. A short target needs standby systems, automation and rehearsal, which cost money. A long target is cheaper and puts revenue, contracts and reputation at risk during the wait. Without a number, nobody knows which one you chose. This links closely with disaster recovery design.
Customers and regulators ask for RTOs by name. Service agreements often promise availability that quietly assumes a recovery time. If your real restore takes two days and your contract says four hours, the gap is a liability that grows with every sale.
How it shows up
Set an RTO for each important service, not one for the company. Rank services by what an outage costs, and give the critical ones the shortest targets. Include everything the service needs: databases, secrets, DNS, third-party providers. A service cannot return faster than its slowest dependency.
Then test it. Time a real restore and compare it with the target. The usual mistakes are numbers chosen to sound good, targets that ignore the time to detect and decide, and never measuring. Pair it with a recovery point objective and review both when the system changes.
Questions people ask
Recovery time objective, answered
What is the difference between RTO and RPO?
RTO is how long you can be down. RPO is how much data you can afford to lose, measured as time since the last good copy.
A service needs both: back quickly and with recent data.
Is the RTO the same as an SLA?
No. An SLA is a promise to customers, often about uptime. An RTO is an internal recovery target.
Your RTOs must be short enough to support whatever the SLA promises.
How do I choose a realistic RTO?
Start from the business cost of downtime for each service, then check what your recovery design can actually deliver in a test.
If the two do not match, change the design or change the promise.
Does the RTO include time to notice the problem?
That depends on how you define it, so write it down. Many teams count from the moment of failure, which includes detection and decision time.
Make the definition clear in the plan.
Can we have different RTOs for different systems?
Yes, and you should. A payment system and an internal wiki do not need the same target.
Tiering services keeps recovery spending where the damage would be greatest. Review the tiers each year.
Sources
Where this comes from
Related
Terms that sit next to this one
Recovery point objective
The most data, measured in time, you can afford to lose.
Disaster recovery
The plan and tools for restoring systems and data after a major failure.
Business continuity
Keeping critical services running, or restoring them fast, through a disruption.
Backup integrity
Knowing your backups are complete, untouched and actually restorable.
Incident severity levels
Agreed tiers that decide how fast and how widely an incident is escalated.
How long can this be down?
A recovery target says how fast you restore. Cyberlop helps reduce what needs restoring, by finding and proving exploitable flaws in your web app before an intruder does. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.