How do you choose the right SLIs for a web service? What makes a good SLI versus a bad one?

Question

Accepted Answer

Choosing the right SLIs is critical because they form the foundation of your entire reliability framework. Bad SLIs lead to misaligned priorities where the team optimizes for metrics that do not reflect what users actually experience. Good SLIs directly capture user happiness.

The fundamental principle is that SLIs should measure things users care about from the user's perspective. A good SLI for a web service answers questions like: can users successfully complete their actions (availability), how long do they wait (latency), and is the data they receive correct (correctness)?

Good SLIs for a typical web service include request success rate measured at the load balancer or API gateway, which captures the user's actual experience of whether requests succeed. Latency measured as percentiles (p50, p95, p99) at the edge rather than at individual backend services, because users experience the total round-trip time. And for data-intensive services, freshness, which measures how up-to-date the data is that users see.

Bad SLIs are typically server-side infrastructure metrics that do not directly correlate with user experience. CPU utilization is a bad SLI because a server can run at 95% CPU while delivering perfect user experience, and conversely a server at 10% CPU can serve broken responses. Similarly, disk usage, memory consumption, and internal queue depth are important operational metrics but poor SLIs because they do not directly reflect what users see.

Where you measure matters as much as what you measure. Measuring latency at the application server misses time spent in the load balancer, network, and CDN. The ideal measurement point is as close to the user as possible. For web services, this means measuring at the load balancer or CDN edge. Synthetic monitoring that runs actual user-like requests from external locations provides the most realistic SLI data.

Keep the number of SLIs small. Two to four SLIs per service is usually sufficient. The Google SRE workbook recommends focusing on availability and latency for most request-serving systems, and availability and freshness for data processing systems. Having too many SLIs dilutes focus and makes it harder to set meaningful SLOs.

Each SLI should be expressed as a ratio or percentage: good events divided by total events. For availability, it is successful requests divided by total requests. For latency, it is requests faster than the threshold divided by total requests. This ratio format makes SLIs easy to set SLOs against and to calculate error budgets from.