What is SLI?

A well formed SLI is a ratio of good events to total events, which makes it naturally bounded and easy to reason about. The proportion of requests returning successfully, or the proportion completing under 300 milliseconds, are both in this form.

The definitional work is in what counts. Which requests are included, what makes a response good, and where the measurement is taken all change the number substantially. An SLI measured at the load balancer and one measured in the browser can differ by a wide margin, and only the second reflects what users experienced.

Everything downstream depends on the indicator being a faithful proxy for user experience.

• Foundation for targets: SLOs and error budgets are meaningless without a sound SLI.
• User alignment: a good indicator moves when users are unhappy and stays flat when they are not.
• Alert quality: alerting on SLI degradation produces meaningful pages rather than noise.
• Prioritization: the indicator that is furthest from target identifies where effort belongs.

Averages are the classic error. Mean latency hides the tail entirely, and the tail is where users abandon. Percentiles, typically the 95th and 99th, describe the experience of the users having the worst time, which is what matters.

Measuring the wrong thing is the other frequent mistake. CPU utilization and queue depth are useful operational signals and poor SLIs, because users do not experience CPU. If an indicator can move sharply without any user noticing, it is not a service level indicator.

The SLI is the measurement, the SLO is the target for that measurement, and the SLA is the contract that attaches consequences to it. In order: 99.95% of requests succeeded is the SLI, 99.9% of requests should succeed is the SLO, and 99.5% or we issue credits is the SLA.

The dependency runs one way. A poorly chosen SLI makes the SLO meaningless and the SLA unenforceable in any useful sense, which is why the indicator deserves more design attention than it usually receives.