What is SLI?

#How SLIs are defined

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.

#Why SLIs matter

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.

#Limits and common mistakes

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.

#SLI vs SLO vs SLA

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.

#Key takeaways

• A good SLI is a ratio of good events to total events, which is bounded and easy to reason about.
• Where the measurement is taken changes the number substantially; closer to the user is more honest.
• Averages hide the tail, so percentiles describe the experience that actually drives user behavior.
• If an indicator can move sharply without users noticing, it is an operational metric rather than an SLI.

#Frequently asked

How many SLIs should a service have?

Two to four. Availability, latency, and correctness cover most services. More indicators dilute attention without adding insight.

Which percentile should latency SLIs use?

Choose percentiles based on user experience, traffic volume, and the tail behavior the service needs to control; there is no universal correct percentile. The median describes the typical user and misses the ones having a bad experience.

Where should SLIs be measured?

As close to the user as practical. Client side measurement includes network and rendering effects that server side measurement misses entirely.

#Sources

• Google SRE: service level objectives