Google SRE Chapter 4 — Service Level Objectives

Chapter 3 planted the seed of the Error Budget. Chapter 4 puts that idea on mathematical footing: SLI, SLO, and SLA — three terms everyone's heard somewhere and almost everyone mixes up. Let's untangle them.

SLI: The Measurement

An SLI (Service Level Indicator) is a concrete, measurable metric that reflects how a service is performing — latency, error rate, throughput, availability, that kind of thing. Google's key warning here: not every metric qualifies as an SLI. A good SLI has to genuinely reflect the user's experience. A system-level metric like CPU usage usually isn't a good SLI, because users don't feel CPU usage — they feel slowness.

SLO: The Target

An SLO is the target value set for an SLI — something like "99.9% of requests respond in under 200ms." The SLO is the direct source of the error budget: if the SLO is 99.9%, the error budget is automatically 0.1%. Google offers a practical piece of advice here worth holding onto: don't set SLOs tighter than they need to be. A target stricter than what's actually achievable just creates unnecessary engineering effort and unnecessary panic.

SLA: The Contract

An SLA is the formal, usually penalty-bearing version of an SLO made with a customer. Google draws a clear line here: an SLA should be looser than the SLO, not the same thing. Breaching an SLA means a refund or a penalty; breaching an SLO means "internal alarm, go fix it." Keeping the SLO consistently tighter than the SLA buys you room to intervene before you ever get near breaking the actual contract.

Picking the Right Metric

One more thing the chapter touches on: where you measure matters. Server-side or client-side? Server-side measurement tends to miss network latency and CDN-level issues entirely. It's also worth looking at percentiles — p50, p95, p99 — rather than averages, since an average can quietly bury the minority of users having a genuinely bad time.

Through a 2026 Lens: Why This Chapter Feels Ordinary

Honestly, I didn't find the depth I was expecting in this chapter — and I think that's actually good news. The SLI/SLO/SLA distinction, checking percentiles instead of trusting averages: all of this is now part of any mid-level engineer's everyday vocabulary. But that very ordinariness tells its own story. In 2016, this chapter was probably new territory for a lot of readers. By 2026, these ideas have become so internalized that they've quietly dropped into the "basic knowledge" bucket — which is really a sign of how much the practice has matured over a decade.

The real difference today is in the tooling. A decade ago, tracking p99 latency, getting it onto the right dashboard, and calculating burn rate took real engineering effort. Today, Grafana, Datadog, and Prometheus's own SLO plugins get you there in a few clicks — often wired straight into a Terraform/GitOps flow through an "SLO as code" approach. The idea Google described hasn't changed; what collapsed is the cost of actually implementing it. That might be the bigger lesson for 2026: once the gap between a good idea and the tooling that makes it accessible closes, the idea stops being "advanced" and just becomes the default.

Next up, Chapter 5: Eliminating Toil — another one of SRE's foundational ideas.

Thanks for reading.