Recovery time objective (RTO)
A recovery time objective is the longest acceptable time to restore a business system after a disruption, so you know which services need fast recovery and which can wait.
A recovery time objective is the longest you can wait for a named system to work again after it fails. The clock runs from the outage to the point staff can do real work, not from when someone starts investigating. Different systems need different figures, because waiting on finance isn't the same as waiting on a reporting tool. The RTO is that operational decision, written down.
You list the systems the business depends on and set a target for each. A four-hour file-server target means backups and spare kit have to exist, with someone on call so the job can finish inside the window. A next-working-day target can sit on slower recovery. The figure belongs in the IT contract so you can separate a response time from a restore time. A restore test is the only way to know the target is real.
It fails when the number is copied from a template and never matched to how the office works. Bringing a server back while staff still cannot sign in doesn't meet the RTO. Another mix-up is treating RTO as data loss: one is time, the other is the last usable copy. An untested backup that restores overnight will miss a four-hour target.
When it matters
- →You cannot name how long each critical system can stay down.
- →Backups exist but nobody has timed a full restore.
- →The IT contract quotes a response time, not a restore time.
- →Payroll, invoicing or a live booking system has no timed recovery plan.
Related terms
Recovery time objective (RTO): common questions
What is the difference between RTO and RPO?
A recovery time objective is how long a system can stay down. A recovery point objective is how much data you can afford to lose, measured as time since the last usable copy. If you set an RTO of four hours and an RPO of fifteen minutes, the service must be back within four hours and you can only lose fifteen minutes of work. They're set separately because a fast restore from a week-old backup still fails the data target.
How do you set a recovery time objective?
Start with the operational cost of an hour of downtime for that system, then decide the longest wait you can accept. Client-facing tools usually need a tighter target than internal reporting. The number only counts if the recovery method can hit it. Backup frequency, spare hardware and who is on call have to match. Write it per system, not as one figure for the whole estate. Then time a restore. If it misses, change the method or lengthen the RTO.
Is RTO the same as an SLA response time?
No. A response time is how quickly a supplier must start work after you report a fault. An RTO is how quickly the service itself must be usable again. A four-hour response can sit next to a next-working-day restore, and the contract is still met. Ask which systems have an RTO, how restore is tested, and what happens if the target is missed. If the paperwork only mentions response or uptime, you don't yet have a recovery commitment.
Ready to talk?
Book a free, no-obligation discovery call. We'll learn about your business and show you exactly how Wanzo can help — with a bespoke proposal within 48 hours.
No commitment. No sales pressure. Just honest advice.