SLOs, Error Budgets, RPO and RTO

1. The problem: four terms, four different questions

When a team says “the service must be 99.9% reliable,” it may be collapsing four separate questions: what user experience matters, what reliability target applies over which window, how much unreliability is acceptable, and how much outage or data loss can be tolerated after a major disruption. This lesson keeps those questions separate.

The owned output is Service Reliability Objective Record v1. The record separates observed evidence, arithmetic, accountable policy decisions, and proof gaps. A neat percentage alone is not a PASS.

2. Start the SLI from user experience

An SLI is a quantitative measure of service level. For a checkout service, “valid purchase attempts completed successfully / all valid purchase attempts” is closer to the user outcome than CPU utilization. CPU may help diagnosis, but it is not automatically the user outcome.

Before selecting a target, state the good event, total event, population, and measurement window. A denominator change can change the meaning of the same percentage.

3. An SLO is a target on an SLI, not current performance

An SLO is a target value or range for an SLI over a declared window. If current performance is 99.93%, that does not make 99.93% the correct objective. The target must be defensible against user need, risk, cost, architecture, and delivery capacity.

This lesson imposes no universal “correct” number such as 99.9%. A target is an accountable decision, not a natural fact about the system.

4. Make good/total and the window explicit

For event-based indicators, a useful form is:

SLI = good_events / total_events

Suppose a 28-day window contains 2,000,000 valid checkout attempts and 1,997,600 satisfy the good-event definition. The observed SLI is 99.88%. That is an observation; it is not yet a policy or a recovery objective.

5. Derive the error budget from the SLO

If the SLO is 99.90%, the allowed bad fraction is 1 - 0.999 = 0.001. For 2,000,000 events, the allowed bad-event budget is 2,000. If 2,400 bad events occurred, 120% of the budget has been consumed.

Budget arithmetic and the decision “what do we do now?” are separate. The arithmetic comes from the SLO and population; the action comes from an approved error-budget policy.

6. Do not invent an error-budget policy

Google SRE describes operational use of an error budget through an explicit policy that says what happens when budget is exhausted. If the fixture supplies no policy, the record must remain POLICY_OPEN; the learner may not invent an organization-specific freeze or threshold.

This distinction matters: “the budget is exhausted” is an arithmetic result; “stop releases” is a governance decision requiring authority.

7. What RTO means

RTO is the maximum acceptable outage duration for a major disruption: how long the business can tolerate loss of the capability before impact becomes unacceptable. RTO comes from the business-impact scenario and risk appetite, not from the SLO percentage.

If the brief states that checkout outage beyond 60 minutes creates unacceptable lost orders and contractual impact, RTO=60m can be recorded as an objective. That still does not prove the architecture can recover in 60 minutes.

8. What RPO means

RPO is the maximum acceptable period/age of data that may be lost or rolled back during recovery. If the business brief tolerates at most five minutes of committed order loss, RPO=5m is an objective.

RPO has architectural consequences for backup frequency, replication, consistency, and restore behavior. But the objective is not inferred merely from the technology currently deployed.

9. SLO/error budget is not RTO/RPO

An SLO asks, “what reliability should users receive over the normal measurement window?” An error budget asks, “how many bad events does that target permit?” RTO asks, “how long may disaster recovery take?” RPO asks, “how much data setback may recovery tolerate?”

A service can meet a monthly SLO and still have no valid DR test for its RTO/RPO. In that case recovery capability remains UNVERIFIED.

10. Recovery objective is not proven capability

Having RTO=30m does not mean the service can recover in 30 minutes. Capability needs evidence such as a restore/failover exercise, start/end timestamps, user-relevant validation, data-integrity checks, and repeatable results.

Likewise, a green backup job does not by itself prove that a usable restore point satisfies the RPO.

11. Record the tradeoff

Tightening an SLO, shortening RTO, or shrinking RPO can change architecture, operations, capacity, replication, and testing cost. A “better” objective is therefore not simply a stricter number; it is one justified by impact and evidence.

Record assumptions and cost implications beside the target so the number does not become unexplained dogma.

12. Service Reliability Objective Record v1

The record contains user journey, SLI definition, good/total population, window, SLO target, observed SLI, error-budget fraction, allowed bad events, observed bad events, budget consumed, policy state, business-impact statement, RTO, RPO, recovery evidence, assumptions, unknowns, and decision state.

This format is a MAKNOW instructional synthesis, not a Google-mandated template. Its value is traceability and keeping distinct operational questions from collapsing into one number.

13. Lab: guided case and negative probes

The lab contains eight local synthetic fixtures. Some contain a user-centered SLI and complete denominator; others contain an easy-but-irrelevant metric, missing policy, RTO/RPO without business authority, or a recovery claim without test evidence.

The hidden oracle does not reward memorizing one percentage. It checks eight independent dimensions in every fixture and requires plausible shortcuts to fail.

14. Transfer and acceptance criteria

The transfer service has a different user journey, traffic population, criticality, and recovery constraint. Targets from the first case cannot be copied. PASS requires a newly justified SLI/window/target, correct budget arithmetic, no invented policy, and RTO/RPO derived from business impact with explicit recovery-evidence gaps.

The four blocking dimensions are SLI/SLO definition, budget arithmetic, RTO/RPO separation, and tradeoff-based transfer.

15. Sources, freshness, and claim limits

Google SRE defines an SLI as a quantitative service-level measure and an SLO as a target on that SLI, and recommends starting from what users care about. Google SRE also derives error budget from the SLO and describes an explicit policy for operational responses. Google Cloud guidance describes RTO as maximum acceptable downtime and RPO as the maximum acceptable data-recovery setback/age.

These sources were rechecked on 2026-09-19. No organization-specific target, policy, or recovery capability is invented from them; anything without authority or test evidence remains OPEN.