An SLI (Service Level Indicator) is a quantitative measure of how well a service performs from the user's point of view, usually expressed as the ratio of good events to valid events, for example the percentage of requests served successfully in under 300 ms. SLIs are the measurements that SLOs and error budgets are built on.
What is an SLI (Service Level Indicator)?
An SLI (Service Level Indicator) is a precisely defined measurement of one aspect of service quality that matters to users. Typical SLIs measure availability, latency, correctness or freshness. An SLI is not a target and not a promise. It is the number you observe. The target placed on it is the SLO, and a contractual commitment with consequences is an SLA.
The most practical form is a ratio of events:
SLI = good_events / valid_events * 100 %Expressing SLIs this way keeps them between 0 and 100 percent, makes them comparable across services and lets you derive an error budget directly: everything that is not good consumes budget.
There are two common ways to count. Request-based SLIs count individual events, such as HTTP requests or processed messages, and weight every user interaction equally. Window-based SLIs divide time into short intervals, for example one minute, and count an interval as good if a condition held, such as an error rate below 1 percent. Request-based SLIs are more precise for high-traffic services. Window-based SLIs are useful when traffic is low or uneven, because a handful of failed requests at night would otherwise dominate the ratio.
Common types of SLIs
| SLI type | Good event | Typical for |
|---|---|---|
| Availability | Request answered without server error | APIs, web front ends |
| Latency | Request answered faster than a threshold, for example 300 ms | Interactive requests |
| Correctness | Response contains the right data | Pricing, search, billing |
| Freshness | Data updated within a defined time | Data pipelines, caches, dashboards |
| Throughput or completion | Job or message processed successfully | Batch jobs, queues |
The golden signals are a good starting point for choosing SLIs, but not every metric is an SLI. CPU usage, for example, says little about user experience and is better used for diagnosis and capacity planning.
How to define a good SLI
A useful SLI specification answers four questions:
- What is a valid event? Which requests count at all? Health checks, bot traffic and requests rejected for bad input (4xx) are often excluded.
- What is a good event? For example a status below 500 and a duration below 300 ms.
- Where is it measured? At the load balancer, in the service, in the browser via real user monitoring or from synthetic probes. The closer to the user, the more realistic, but also the noisier.
- Over which window? SLIs are evaluated over a rolling window, commonly 28 or 30 days, and over short windows for alerting.
Example: latency and availability SLIs
An illustrative checkout API with histogram metrics in Prometheus format could define two SLIs:
# Availability: share of non-5xx requests
sum(rate(http_server_requests_total{service="checkout",code!~"5.."}[5m]))
/
sum(rate(http_server_requests_total{service="checkout"}[5m]))
# Latency: share of requests faster than 300 ms
sum(rate(http_server_duration_seconds_bucket{service="checkout",le="0.3"}[5m]))
/
sum(rate(http_server_duration_seconds_count{service="checkout"}[5m]))If, over 30 days, 9,990,000 of 10,000,000 valid requests are good, the availability SLI is 99.9 percent. Note that the latency SLI counts requests below a threshold instead of reporting a percentile. Threshold-based ratios can be aggregated across instances and time windows correctly, while averaging percentiles cannot.
The same ratios work for short and long windows. Evaluated over 30 days they show whether the SLO is met. Evaluated over 5 minutes or 1 hour they drive burn-rate alerts that warn when the budget is being consumed too fast.
Best practices
- Start with a few SLIs per user journey, such as login, search and checkout, rather than dozens per service.
- Measure as close to the user as practical, and validate server-side SLIs against real user data.
- Choose histogram bucket boundaries that match your latency thresholds, so the SLI can be computed exactly.
- Version SLI definitions and review them when the product changes. A changed definition breaks the history.
- Connect every SLI to an SLO, an error budget and an alerting policy, otherwise it remains just another chart.
Common mistakes
- Using averages, such as mean latency, which hide the slow requests that users actually notice.
- Counting client errors as failures, which lets misbehaving clients burn your budget.
- Measuring only inside the service and missing failures in the load balancer, DNS or CDN.
- Picking SLIs because data is easy to get rather than because they reflect user experience.
How Obseria helps
Obseria lets you define SLIs as good-to-valid ratios on metrics, traces or real user data, using PromQL, OQL or SQL. Each SLI feeds an SLO with error budget tracking and multi-window burn-rate alerts. Because metrics are retained for 13 months, you can compare SLI trends across quarters.
