What is RTO (recovery time objective)?
Most teams find out their real RTO during the first outage. That is when someone with a stake in the answer finally times it.
Recovery time objective (RTO)
RTO
Recovery time objective, or RTO, is the longest a system can be down after a failure before the outage causes real damage to the business. It is a target you set before the failure. It is not a number you measure after one.
RTO answers one question: how long can this be down? Not how long it takes engineers to fix the underlying bug. Just the clock from the moment a system fails to the moment it is back and usable, at whatever level was agreed on.
That number is set by what the business can absorb, not by what the infrastructure can technically achieve. A checkout system might need an RTO of minutes. An internal reporting tool might tolerate a day. The technology gets built to hit whichever target the business actually needs, and a target nobody wrote down defaults to however long the fix takes.
The number a business decides, not a number engineering finds
Set RTO before you design for it, and the order of decisions works. Skip that step, and the RTO becomes whatever the architecture happens to deliver. It gets discovered for the first time during a real outage, at the worst possible price.
Every hour of the target has a cost attached. A four-hour RTO can often run on a single standby database and a documented failover step. A four-minute RTO usually needs an active-active setup running in two places at once. It has to be tested on a schedule, not described once in a document. Neither is wrong. The mistake is picking the architecture first and calling whatever it produces the RTO.
We ask for the RTO before we propose a recovery design, on every maintenance engagement that includes disaster recovery. A number picked after the outage is not a target. It is an excuse with a timestamp.
- Business sets the numberHours or minutes the outage costs are worth.
- Failure happensClock starts, whether anyone is watching or not.
- DetectionTime before anyone knows it failed.
- Failover or restoreThe step that brings the system back.
- VerifyBack up is not the same as back and correct.
- Target met or missedMeasured against the number set at the start.
Detection time is the part most RTO plans forget to count. A system down for ten minutes before anyone notices has already spent ten minutes of a thirty-minute target.
Common questions
01What 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 in time since the last good backup. A system can have a tight RTO and a loose RPO, or the reverse. The two get set separately, because they usually cost different amounts to hit.
02How do you actually set an RTO?
Start with what an hour of downtime costs the business, in lost revenue, missed obligations, or reputational damage, and work backward from there. A payment system and an internal dashboard rarely share a number. The answer comes from the business side of the table, then engineering designs to hit it.
03Does every system need a short RTO?
No, and treating every system the same way wastes money on the low-stakes ones while under-protecting the ones that matter. A tiered approach is normal: a short RTO for revenue-critical systems, a longer one for internal tools. It usually costs less than one blanket target.
04Can you have an RTO of zero?
Only with active-active infrastructure running in more than one location at once, and even then something briefly notices the failure and reroutes traffic. A true zero is rare and expensive to sustain. Most systems that claim it actually run a very short RTO, in seconds, not a true zero.
Related terms
- Software maintenance →Where an RTO gets tested and written into an ongoing support contract.
- SLA (service-level agreement) →The contract term that turns a response target into something you can be held to.
- Rollback →Why a code rollback is fast and a database migration or a sent message is not, inside the same recovery clock.
