What Exactly Are We Measuring?
An SLI (Service Level Indicator) is a direct, quantitative measurement of a service's behavior that correlates with user happiness. It answers the question: what is actually happening right now, from the user's perspective?
An SLI is not a system metric like "CPU usage," "free disk space," or "network throughput." Users don't care about your CPU. They care whether the page loads, whether their payment goes through, and whether the search results appear quickly. A good SLI measures the outcome the user experiences, not the internal state of your infrastructure.
The Standard Formula
Almost all good SLIs can be expressed as a ratio of "good" events to "total" events over a specific time window:
$$\text{SLI} = \left( \frac{\text{Count of Good Events}}{\text{Count of Total Valid Events}} \right) \times 100$$
The result is a percentage. The key design decision is defining what "good" means for your specific service.
Common SLI Categories
Availability SLI — Did the service respond at all?
- Good Event: An HTTP request that returns a non-5xx status code.
- Total Events: All HTTP requests.
- Example SLI: "99.5% of all HTTP requests resulted in a non-error response over the last 30 days."
Latency SLI — Did the service respond fast enough?
- Good Event: A request served in under 300ms (measured at the 99th percentile).
- Total Events: All valid requests.
- Example SLI: "98% of requests were served in under 300ms over the last 24 hours."
Quality SLI — Was the response correct and complete?
- Good Event: A search query that returns results (not a degraded empty-result fallback).
- Total Events: All search queries.
- Example SLI: "99.2% of search queries returned non-empty results."
Durability SLI — Was stored data retrievable?
- Good Event: A stored object that can be successfully read back.
- Total Events: All objects written.
- Example SLI: "99.9999% of stored objects are retrievable." (Common for storage systems.)
What Makes a Good SLI
A well-designed SLI has three properties:
1. It correlates with user happiness. If the SLI is good, users are happy. If it degrades, users notice.
2. It is measurable. You can compute it from logs, metrics, or synthetic probes.
3. It excludes noise. Health check pings, internal traffic, and known-bad clients should be excluded from "total valid events" so they don't distort the measurement.
Interviewers often ask: "What's the difference between an SLI and a system metric like CPU usage?" The answer is that system metrics measure internal state — they tell you about your infrastructure. SLIs measure user-facing outcomes — they tell you whether users are getting the service they expect. A service can have 100% CPU and still be serving users perfectly (batch workload), or have 10% CPU and be returning errors to everyone (application bug). Always tie SLIs to user experience, not infrastructure health.