Recovery objectives (RTO/RPO) vs Service level objective (SLO)

Incidents & continuity

Two agreed limits for a failure - how long a system may be down (RTO) and how much recent data may be lost (RPO).

Formal

The recovery time objective (RTO) is the longest a system or process may be unavailable before the harm becomes unacceptable. The recovery point objective (RPO) is the oldest point in time the data may be restored to, which sets how often a backup must be taken.

In plain English

If your phone dies, RTO is how long you can manage without one; RPO is how many days of photos you could stand to lose since your last copy.

In practice

A Danish web shop decides its order system needs an RTO of four hours and an RPO of fifteen minutes, so it copies orders to a second location every fifteen minutes and practises a switch-over twice a year.

Why it matters

The two numbers turn a vague wish to "be back quickly" into a clear target that decides how much to spend on backup and spare systems.

Service level objective (SLO)

Observability

An internal target for how well a service should work, such as 99.9% of requests answered within a second over 30 days.

Formal

A target value for a measured sign of service quality, such as the share of requests that succeed or answer fast enough, over a set time window; the gap between the target and 100% is the error budget the team may spend.

In plain English

Like a bus company aiming for 98% of buses on time; the timetable it prints for passengers promises less, so it has room to spare before it owes anyone money.

In practice

The team behind a school communication portal allows itself 43 minutes out of service a month; after a bad release uses 40 of them, it pauses new features and spends the rest of the month on stability.

Why it matters

It turns availability from a vague wish into a number that guides the choice between speed and stability, and warns the team before it breaks the SLA it has given its own customers.

Shared connections

Availability