SLIs, SLOs, SLAs, Error Budgets, and Reliability Trade-offs

Mission

By the end of this chapter, you can define a user-centered SLI, justify an SLO, distinguish an SLA, and apply an error-budget policy to a release decision.

• Measurable outcome: Define one user-centered SLI, one bounded SLO, and an error-budget response policy that a Product, Engineering, and SRE group can use to make a release trade-off; score at least 3 of 4.
• Prerequisites: Chapters 7, 13, 20, and 25.
• Work product: A one-page Service Level Decision Record.
• Time: 65–85 minutes.

Before you read: Predict → Commit → Connect

Meridian Pay’s API is available 99.99% of the month, yet merchants report that settlement files often arrive after their accounting cutoff. Is the service reliable? Commit to yes, no, or “not enough information,” and write the missing measurement.

Connect to Chapter 20: a metric becomes useful when it changes a decision. Infrastructure uptime that ignores the user’s deadline may be accurately measured and strategically useless.

Four terms, four different jobs

An SLI, or service level indicator, is a quantitative measure of behavior experienced by a defined population: for example, the proportion of eligible settlement files delivered complete by 06:00 merchant-local time.

An SLO, or service level objective, is the target range for that SLI over a stated window: for example, at least 99.5% over a rolling 28 days, with no priority merchant missing two consecutive cutoffs.

An SLA, or service level agreement, is an external or contractual promise that may specify remedies or consequences. An SLA should normally leave operational margin inside the internal SLO; teams need room to detect degradation and act before breaching a promise.

An error budget is the permitted unreliability implied by an SLO. For an availability-style target, it is conceptually 100% minus the SLO. A 99.9% success target permits 0.1% unsuccessful eligible events in the window. This is not permission to spend harm carelessly. It is a control signal for balancing reliability work with change.

The language is simple; choosing well is not. First define the population, success, measurement point, window, and exclusions. “Latency below 300 ms” is incomplete. Which requests? Measured at the client, edge, or service? What percentile or proportion? Over what period? Are retries counted? An SLI can be gamed accidentally when its denominator omits the hardest traffic.

Measure the journey, not the component alone

Start with a user journey and a consequence. Meridian’s merchant does not care whether the file generator had uptime; the merchant cares whether a complete, correct file arrives before the cutoff. Component SLIs still help diagnose the path, but the decision SLO should represent the experience the program promises to protect.

Use a small set. Too many SLOs diffuse attention and create contradictory incentives. For each, document why the target is neither lower nor higher. A higher target usually costs capacity, engineering time, release flexibility, and operational complexity. Some journeys merit it because harm is severe. Others benefit more from faster learning or richer functionality.

An error-budget policy turns measurement into action. It may specify what happens when burn is fast, sustained, or concentrated in a severe event: pause risky releases, require a learning review, increase review rigor, or prioritize the dominant failure mode. Do not copy Google’s sample thresholds as universal law. Select thresholds from your own user harm, traffic, release model, and response capability.

“Burn rate” describes how quickly the budget is being consumed relative to a sustainable pace. Fast burn needs urgent containment; slow burn may need planned correction. Averages can hide sharp regional or customer-class failures, so segment when the segment represents different harm.

Decision rights: Who owns what?

• Product identifies critical journeys, user harm, and the value of change.
• Engineering implements instrumentation and owns technical changes that improve or consume reliability.
• SRE/Operations normally stewards SLI quality, SLO practice, alerting, and operational response policy.
• Legal/Commercial leadership owns contractual SLA language and remedies with technical input.
• The TPM aligns the journey, dependency-level measures, target rationale, release policy, and decision cadence. The TPM exposes when teams optimize component health while the end-to-end outcome fails.
• The authorized business/technical leaders resolve an explicit feature-versus-reliability trade-off; no metric makes the judgment automatically.

I do

For Meridian, I reject “API uptime” as the sole program SLI. I propose:

Of settlement files due for supported merchants, the proportion delivered complete, reconciled, and readable by 06:00 merchant-local time, measured at confirmed merchant-accessible storage, over a rolling 28-day window.

I then add diagnostic SLIs for extraction completion, regional transfer, reconciliation mismatch, and notification delivery. The end-to-end SLO drives the decision; component measures locate the seam that failed.

We do

Helios Support answers quickly, but 4% of answers are handed to a human because the system lacks sufficient evidence. Product wants to classify handoff as failure; Operations calls it a safe success.

Together define two indicators rather than forcing one moral judgment into a denominator: (1) safe resolution or appropriate handoff and (2) autonomous resolution that later remains accepted. Decide which is a reliability SLO and which is a product-effectiveness measure.

You do

Complete this Service Level Decision Record:

Test it with three scenarios: one severe short incident, a low-grade month-long degradation, and a failure isolated to one region. State what decision changes in each.

Pause & Recall

From memory, define SLI, SLO, SLA, and error budget without using each term in its own definition. Recall Chapter 15: how can a dependency outside your team invalidate an end-to-end SLO? Recall Chapter 25: which readiness evidence proves the measurement itself works before launch?

Production lens

SLIs are software and therefore can fail. Audit missing telemetry, delayed events, duplicate requests, client-versus-server disagreement, and excluded traffic. Review SLOs when journeys, architecture, customers, or consequences change. Never let an SLO erase a severe event merely because the monthly average remains green.

Workplace artifact: reliability trade-off statement

Copyable trade-off statement

The [journey] SLO is [target/window]. Current burn is [pattern], concentrated in [segment/cause]. Continuing [change] creates [benefit] but risks [harm]. Under the agreed policy, I recommend [continue/limit/pause] until [evidence or correction]. Product owns the value trade-off, Engineering/SRE own remediation evidence, and [authority] closes the decision by [time].

Chapter compression

SLI measures behavior; SLO sets the target and window; SLA makes an external promise; error budget converts the SLO into a change-versus-reliability control signal. Center the user journey, document the denominator, and connect budget consumption to a pre-agreed response.

Retrieval deck

• Q: Why is uptime often insufficient? A: It may not represent completion, correctness, timeliness, or the user’s observation point.
• Q: Why should an internal SLO usually be tighter than an SLA? A: It creates operating margin to act before breaching an external promise.
• Q: What makes an error budget useful? A: An agreed policy that changes release and reliability decisions.
• Q: What is denominator risk? A: Excluding or misclassifying difficult events so the indicator looks healthy while users suffer.
• Q: Who sets the final trade-off? A: The locally authorized product/business and technical leaders, informed by SRE evidence; the TPM integrates the decision.

Spaced review

• Now: Write the user journey, eligible population, and good event for one service.
• +1 day: Define SLI, SLO, SLA, and error budget from memory.
• +3 days: Add a window, target rationale, and denominator-risk check.
• +7 days: Redesign one component metric as a journey SLI.
• +14 days: Run three burn scenarios through the policy and revise ambiguous actions.

Sources and further study

• Google SRE: Service Level Objectives (2016)
• Google SRE Workbook: Implementing SLOs (2018)
• Google SRE Workbook: Error Budget Policy (2018; sample policy)
• DORA: Current software-delivery performance metrics (updated January 5, 2026)
• NASA: Systems Engineering Handbook, Revision 2 (2016)