A service level indicator (SLI) is a quantitative measure of one aspect of service reliability as users experience it, usually expressed as the ratio of good events to valid events over a time window. In observability and site reliability engineering, the SLI is the measured number, the service level objective sets the target for it, and the service level agreement adds contractual consequences.
Typical SLIs measure availability, latency, correctness, freshness or throughput. A well-chosen SLI answers a simple question, such as what share of checkout requests succeeded within 300 milliseconds, and it becomes the basis for error budgets, alerting and reliability decisions across Cloud services.
How a service level indicator is calculated
The recommended form is a proportion between 0 and 100 percent: the number of good events divided by the number of valid events. Expressing every SLI as a ratio makes indicators comparable, keeps 100 percent as the ideal and allows an error budget to be derived directly as the remaining share.
Three definitions must be explicit. Valid events state what is counted at all, for example HTTP requests to public endpoints excluding health checks. Good events state what counts as success, such as a non-5xx status returned within a latency threshold. The measurement window, often a rolling 28 or 30 days, states the period over which the ratio is computed.
The following table shows common SLI types with typical good-event definitions.
| SLI type | Good event definition | Typical service |
|---|---|---|
| Availability | Request completed without a server error | APIs and web front ends |
| Latency | Request served faster than a threshold such as 300 ms | Interactive applications |
| Correctness | Response contains the right data | Payment and pricing systems |
| Freshness | Data updated within a set age such as 10 minutes | Data pipelines and caches |
| Throughput or coverage | Records processed out of records received | Batch and streaming jobs |
| Durability | Stored objects that remain readable | Storage platforms |
Where SLI data is measured
The measurement point changes what an SLI can see. Measuring closer to the user captures more real failures but is noisier and harder to collect; measuring inside the service is precise but misses failures in load balancers, DNS or client networks.
| Source | Strength | Blind spot |
|---|---|---|
| Application metrics | Detailed and cheap to collect | Misses requests that never reach the service |
| Load balancer logs | Covers most server-side failures | Misses client and network problems |
| Synthetic probes | Detects outages even without traffic | Tests only scripted paths |
| Real user monitoring | Reflects actual user experience | Affected by user devices and networks |
Most teams start from load balancer or ingress metrics because they balance coverage and effort, then add synthetic probes for low-traffic services where a few failed requests would otherwise distort the ratio.
SLI, SLO and SLA compared
The three terms form a hierarchy and are often used loosely. Keeping them distinct avoids confusion between what is measured, what is targeted and what is promised.
| Term | Question it answers | Example |
|---|---|---|
| Service level indicator | How reliable was the service? | 99.95 percent of requests succeeded last month |
| Service level objective | How reliable should it be? | At least 99.9 percent over 30 days |
| Service level agreement | What happens if it is not? | Service credit when availability falls below 99.5 percent |
| Error budget | How much unreliability is acceptable? | 0.1 percent of requests, about 43 minutes of full outage per 30 days |
SLIs also differ from golden signals such as latency, traffic, errors and saturation. Golden signals are broad monitoring metrics, many of them internal, while an SLI is a user-centered ratio with an explicit success definition. Saturation, for example, is a useful warning signal but rarely a good SLI, because users do not experience CPU usage directly.
Choosing good indicators
Good SLIs reflect critical user journeys, such as logging in, searching or paying, rather than individual components. A service with ten microservices may need only two or three SLIs if they capture what users depend on.
- Prefer percentile-aware latency thresholds over averages, because averages hide the slow tail that users notice.
- Use several latency thresholds when needed, for example 90 percent under 200 ms and 99 percent under 1 second.
- Exclude invalid events deliberately, such as client errors caused by bad input, and document the exclusion.
- Keep the number small: a handful of meaningful SLIs per service is easier to act on than dozens.
- Watch metric cardinality, because splitting an SLI by every customer or endpoint can overload the metrics backend.
Instrumentation matters as much as the definition. SLIs are usually built from counters of good and total events rather than from precomputed percentages, because counters can be aggregated correctly across instances, regions and time windows, while averaging percentages gives misleading results. In tools such as Prometheus, this means recording request counts and latency histograms with buckets near the threshold, so the share of requests under 300 ms can be computed exactly.
Pitfalls in practice
The most common failure is an SLI that stays green while users suffer, for example an availability ratio measured on the server that ignores timeouts at the edge. Another is an indicator so sensitive that it triggers constant alerts and contributes to alert fatigue.
Low traffic also distorts ratios: with 200 requests per day, two failures already mean 99 percent. Longer windows, synthetic traffic or aggregating related endpoints make such SLIs statistically meaningful. Finally, an SLI definition should be versioned and reviewed, because silently changing what counts as a good event makes historical comparisons meaningless.
SLIs become most useful when they drive decisions. Burn-rate alerts compare how fast the current error ratio consumes the error budget, so a short, severe outage and a slow, persistent degradation both trigger action at the right moment, while brief harmless spikes do not wake anyone.
The idea in brief
A service level indicator is a report card score for a digital service. It counts how many times the service did what users needed, quickly and correctly, out of all the times they tried.
If 999 out of 1,000 page loads worked properly, the score is 99.9 percent. Teams compare that score with their goal to decide whether to focus on new features or on fixing reliability.
A practical scenario
An online food ordering platform noticed that customers complained about slow checkouts even though server dashboards showed normal CPU usage and few errors. The reliability team defined two SLIs for the checkout journey, measured at the load balancer: availability as the share of non-5xx responses and latency as the share of requests completed within 800 milliseconds.
The latency SLI immediately showed only 97.8 percent good events during evening peaks, against an objective of 99 percent. Tracing revealed a slow call to an address validation service. After caching validation results, the latency SLI rose above 99.5 percent, and the team switched alerting from CPU thresholds to burn-rate alerts on the two SLIs, which reduced pages while catching real user impact earlier.