SLIs & SLOs: Measuring What Matters for Service Reliability

WHY IT EXISTS: It's impossible to manage a service well without understanding which behaviors truly matter and how to measure them. Without objective measures, you're relying on intuition to define and deliver a given level of service, which doesn't scale and leads to disagreements about priorities.

THE MENTAL MODEL: An SLI (Service Level Indicator) is the thermometer measuring your service's health—a specific, quantitative metric like request latency or error rate. An SLO (Service Level Objective) is the target temperature you're aiming for, like "99.9% of requests should be faster than 300ms." Together, they replace vague feelings about reliability with a precise, data-driven framework.

HOW IT WORKS: The process starts by defining what matters to your users. First, you choose a Service Level Indicator (SLI), which is a quantitative measure of some aspect of your service. Common SLIs include request latency, error rate as a fraction of total requests, and system throughput in requests per second. The measurement is often aggregated as a rate, average, or percentile. Second, you define a Service Level Objective (SLO), which is a target value or range for your SLI. For example, an SLO for latency might be that 99% of requests are served in under 100ms. This target is a conscious trade-off; aiming for 100% is impossible and leads to over-engineering.

WHEN TO USE IT: Use this framework for any service where reliability directly impacts users. This applies to public products, internal APIs, and data processing pipelines. Key SLIs include availability (the fraction of time a service is usable), latency (how long a request takes), and durability (for storage systems, the likelihood that data is retained over time). It provides a common language for engineering, product, and operations teams to discuss and agree upon reliability goals.

WHEN NOT TO USE IT: The overhead of defining, measuring, and acting on SLOs may not be justified for systems with no direct users or loose performance requirements. For example, an internal batch job that can be easily rerun after a failure might not need a formal SLO. The goal is to focus effort where it improves the user experience.

ONE CANONICAL EXAMPLE: Google Compute Engine has a published availability SLO. The SLI is availability, measured as the fraction of time the service is usable. The SLO is "three and a half nines," or 99.95% availability. This target dictates that the service can be unavailable for no more than approximately 22 minutes per month. This single, clear objective drives engineering priorities and operational responses for the entire service.