---
title: "Recovery Time Objective (RTO) — monitoring glossary"
description: "Recovery Time Objective (RTO) is the maximum acceptable time a system can be offline after an incident before the business impact becomes unacceptable. RTO…"
canonical: "https://lemwatch.com/glossary/rto"
source: "https://lemwatch.com"
---

# 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…

**Also known as:** Recovery Time Target

## Definition

 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.


## Related

- [Monitoring glossary](https://lemwatch.com/glossary)
- [Recovery Point Objective](https://lemwatch.com/glossary/rpo)
- [MTTR](https://lemwatch.com/glossary/mttr)
- [Incident](https://lemwatch.com/glossary/incident)
- [SLA](https://lemwatch.com/glossary/sla)
- [Mean Time Between Failures](https://lemwatch.com/glossary/mtbf)
- [All monitoring checks](https://lemwatch.com/features)
- [Real User Monitoring (RUM)](https://lemwatch.com/glossary/rum)