A recovery time objective (RTO) is the longest a system, application or business process can stay unavailable after a disruption before it must be running again. It is set in advance, as a planning target, and expressed as a duration: four hours for an order system, two days for an internal reporting tool. The RTO tells IT how fast recovery needs to be, which in turn decides what recovery approach, and how much spending, each system justifies.
At a glance
- RTO measures tolerable downtime: the gap between a disruption and the system being usable again.
- It is a business target, ideally set through a business impact analysis, not a technical setting.
- Shorter RTOs generally cost more, so systems are usually grouped into recovery tiers.
- RTO is paired with recovery point objective (RPO), which measures tolerable data loss.
- A target only means something once it has been tested against a timed recovery.
What problem it solves
Without an agreed RTO, everyone has a different idea of how long an outage is acceptable. Leadership may assume the company can be back in an hour; the IT team may know that restoring the main database from backup takes most of a day. That gap usually surfaces during a real incident, which is the worst time to discover it.
An RTO turns “as fast as possible” into a number that can be designed, priced and tested. It lets the business decide where fast recovery is worth paying for, and lets IT explain what the current setup can actually deliver. It also gives insurers, auditors and customers a concrete answer when they ask how quickly you can recover.
How it works
Set it from business impact. A business impact analysis (BIA) looks at each business process and asks what happens as an outage grows longer: lost revenue, missed obligations, safety or regulatory exposure, reputational harm. The point at which the damage becomes unacceptable sets the outer limit, and the RTO is set inside it.
Tier the systems. Systems that support the same process share its RTO. Most organizations end up with a handful of tiers rather than a separate number for every server, which keeps planning and testing manageable.
Pick a recovery approach that fits. Long RTOs can often be met by restoring from backup. Shorter ones typically need copies kept ready to start on alternate infrastructure, as in disaster recovery as a service (DRaaS). Systems that can tolerate almost no downtime usually need redundancy built in, such as high availability (HA) designs, rather than recovery after the fact.
Count the whole timeline. Recovery time includes noticing the problem, deciding to invoke recovery, restoring or starting systems, reconnecting networks and users, and checking that everything works. The restore step is often the smallest part.
Test and adjust. Timed recovery tests show whether the target is realistic. If they miss, either the design changes or the business accepts a longer RTO.
When it matters for buyers
- When buying backup, DRaaS or managed recovery services. Your RTOs decide which service model and tier you need, and they are the yardstick for comparing quotes.
- When cyber insurance renews. Insurers often ask about recovery capabilities and testing, and documented, tested RTOs make those answers credible.
- After an outage. A real incident shows whether your targets matched reality and is often the moment budgets open up.
- When a customer or contract asks for recovery commitments. You can’t promise a customer a recovery time you haven’t designed for.
- When moving systems to the cloud or SaaS. Recovery responsibilities shift, and RTOs need to be checked against what each provider actually commits to.
Questions to ask vendors
- What recovery times have customers like us achieved in tests, and how were they measured?
- When does the recovery clock start in your commitment: at the incident, when we report it, or when we formally declare a disaster?
- Which steps does your commitment cover, and which are ours (networking, user access, application checks)?
- What happens to recovery times if many customers invoke recovery at once, as in a regional event?
- How many recovery tests are included each year, and do you help run and time them?
- What remedy applies if a contractual recovery time is missed?
How it differs from RPO
RTO and recovery point objective (RPO) are usually quoted together, but they measure different things. RTO looks forward from the disruption: how long until the system is usable again. RPO looks backward: how much data, measured in time, you can afford to lose because it changed after the last good copy. A nightly backup gives an RPO of up to a day no matter how quickly you restore it; a system replicated every few minutes can still have a long RTO if nobody has planned how to start it elsewhere. Both feed into a wider business continuity and disaster recovery (BCDR) plan, and providers may express their own commitments in a service level agreement (SLA) that uses different measures from your internal targets. Our disaster recovery as a service overview covers how providers design for different RTOs.