SLO Document: Your Service's Reliability Contract

WHY IT EXISTS To move beyond vague statements like "the service needs to be reliable" and create a precise, shared understanding of performance targets. It formalizes the agreement between stakeholders, like product and engineering, on what level of reliability is required and what is acceptable, forming the basis for the error budget.

THE MENTAL MODEL Think of an SLO document as a formal contract for your service's reliability. It's not just a list of metrics; it's a negotiated agreement that defines "good enough" performance. This contract specifies exactly what you'll measure (Service Level Indicators or SLIs) and what percentage target you're committing to (Service Level Objectives or SLOs).

HOW IT WORKS An SLO document starts with a service overview, then presents a table of SLIs and SLOs. For each critical user journey, it defines SLIs for categories like Availability, Latency, Freshness, or Correctness. Each SLI has a precise, technical definition (e.g., "Availability is the proportion of non-5xx HTTP responses from the load balancer") and a target SLO (e.g., "99.9% over a 28-day rolling window"). The document must also include a rationale explaining how and why these targets were chosen.

WHEN TO USE IT Use an SLO document for any service where reliability is important to users and the business. It's essential for aligning engineering efforts with product goals, making data-driven decisions about deploying new features versus fixing bugs, and calculating the error budget that governs development velocity.

WHEN NOT TO USE IT A formal SLO document is overkill for early-stage prototypes, internal tools with no critical dependencies, or services where user expectations for reliability are undefined. If you cannot measure an SLI accurately and consistently, you cannot have a meaningful SLO for it.

ONE CANONICAL EXAMPLE A gaming service's SLO document might specify multiple objectives. For API availability, the SLI could be the percentage of non-5xx HTTP requests, with an SLO of 97%. For latency, it might have two SLOs: 90% of requests served in under 400ms and 99% under 850ms. For a data pipeline feeding leaderboards, a freshness SLO could be "99% of reads use data less than 10 minutes old."