RTO
Recovery time objective: the target duration within which a service should be restored after a disruption.
Also called: Recovery time objective
In practice
RTO is a stated intention, not a measurement. It says how long the organisation has decided a service may be unavailable before the consequences become unacceptable, and it is set by the people who bear those consequences rather than by the people who operate the systems.
That makes it different from mean time to repair, which describes what recovery actually takes on average. RTO is the requirement; MTTR is the observed behaviour. The interesting work happens in the gap between them: an RTO of fifteen minutes against an MTTR measured in hours is not a plan, it is a statement that the current architecture does not meet the requirement.
Meeting a short RTO is an architecture question rather than an effort question. It generally means failover that does not wait for a human decision, capacity that is already running elsewhere, and recovery procedures that have been rehearsed rather than written. Each of those is a cost, which is why RTO is negotiated per service instead of being set once for everything.
It travels with recovery point objective, which asks a different question — how much data loss is tolerable. The two together describe what a recovery has to achieve, and they frequently pull in different directions.
Scope of this definition
This is an educational summary of how the term is used in data center practice. It is not a standard, a specification or engineering advice, and where a real decision depends on it, the current adopted standards, verified site information and qualified professional review are the correct sources.