Recovery Time Objective
also called RTO
The maximum acceptable duration between a failure and restored service, agreed with the business rather than chosen by engineering.
RTO is the time dimension of recovery; RPO is the data loss dimension. They are set independently, and confusing them produces designs that satisfy neither.
The tiers and what they imply: minutes requires a warm or active standby with automated failover. Hours allows a warm standby with manual promotion. Days allows restore-from-backup. Each step down is materially more expensive, so tiering by application matters — a payments path and an internal reporting tool should not share an RTO.
Three things that make a stated RTO fictional:
It has never been tested. An untested recovery procedure has an unknown RTO, and the discovered value is reliably larger than the documented one.
It excludes decision time. Detection, escalation, and the decision to fail over often exceed the technical recovery, and are usually omitted from the estimate.
It ignores dependency order. Recovering a service whose database is not yet available does not count. The real RTO is the critical path through the whole dependency graph, which is why per-service RTOs do not compose.