Monitoring
Recovery Time Objective
RTO
Recovery Time Objective (RTO) is the maximum acceptable time a system can be offline after an incident before the business impact becomes unacceptable. RTO drives the design of failover, backups, and incident response — a 15-minute RTO demands very different infrastructure from a 24-hour RTO.
In depth
RTO is set by the business, not the engineering team. It answers the question: how long can we survive without this service? A customer-facing checkout might have an RTO of 5 minutes; an internal HR portal might have an RTO of 8 hours.
Once RTO is fixed, engineering picks the architecture that hits it: hot standby, warm standby, cold restore, or best-effort rebuild. Uptime monitoring feeds RTO by measuring actual mean time to recovery (MTTR) against the target — if MTTR trends above RTO, the SLA is at risk.
Why it matters
Without an RTO, incidents drift. Teams debate 'is this bad enough to page the CTO?' during the outage instead of before it. Publishing an RTO per service turns incident response into a checklist, cuts MTTR, and gives leadership a hard number to invest against.
Also known as
- Recovery Time Target
Related terms
Recovery Point Objective
Recovery Point Objective (RPO) is the maximum amount of data loss (measured in time) a business can tolerate a…
MTTR
Mean Time To Recovery (MTTR) measures the average time it takes to restore service after an incident begins. I…
Incident
An incident is a confirmed period of degraded or unavailable service that requires human attention. Incidents …
SLA
A service level agreement (SLA) is a contractual commitment between a provider and a customer specifying a mea…
Status Page
A status page is a public dashboard that displays the current health of a service and the history of past inci…
Browse the full Lemwatch monitoring glossary (47 terms).