A service level indicator (SLI) is a measurement of how a service is actually performing for its users, usually the percentage of valid events that were good. It is the number an SLO sets a target for.
What is an SLI?
A Service Level Indicator (SLI) is a quantitative measurement of a service’s reliability or performance. SLIs measure how well a service behaves from the user’s perspective: whether requests succeed, how fast they are served, and whether the results are right.
An SLI is the first of three related numbers. The SLI is what is happening, the SLO is the target for it, and the SLA is what has been promised to customers. SLO vs SLA vs SLI compares all three.
How to calculate an SLI
Most SLIs are a ratio of good events to valid events, expressed as a percentage:
SLI = (good events ÷ valid events) × 100Imagine an API receives 100,000 valid requests during a measurement period. Of those, 99,950 complete successfully.
SLI = (99,950 ÷ 100,000) × 100 = 99.95%This tells the engineering team that 99.95% of valid requests were served successfully. The SLI alone does not say whether that is acceptable. That requires an SLO, such as 99.9% over 30 days.
Writing an SLI as good events over valid events keeps it on a 0 to 100% scale, makes it comparable across services, and makes the error budget simple to work out.
What are the types of SLI?
Four types cover most request-driven and data services:
| SLI type | What it measures | Example SLI |
|---|---|---|
| Availability | Share of valid requests that succeed | 99.95% of checkout requests return a successful response |
| Latency | Share of valid requests served faster than a threshold | 98% of search requests complete in under 500 ms |
| Correctness | Share of responses that return the right result | 99.99% of balance lookups match the ledger |
| Freshness | Share of data updated within a time limit | 99.5% of shipment updates are visible within 5 minutes |
Latency SLIs work best as the share of requests under a threshold, not as an average. An average can look healthy while a slow tail of requests hurts many users.
What makes a good SLI?
A useful SLI reflects an experience that matters to users. Monitoring whether a server is running may not show whether customers can complete a payment or reach their accounts.
A service can have healthy infrastructure while users experience failed transactions, incorrect responses, or excessive latency.
- Hosts up12 / 12
- CPU41%
- Memory63%
- Health check200 OK
- Payments that succeed97.8%
- p95 checkout latency2.4 s
- Orders confirmed96.9%
- Log-ins that succeed99.98%
A good SLI is built from the right-hand view.
A good SLI measures the reliability of the service users depend on, not just the health of the infrastructure supporting it.
In practice, a good SLI:
- Measures an outcome users notice: a completed payment, a page that loads, a shipment that is assigned.
- Defines good and valid events precisely: which status codes count as failures, which latency threshold counts as slow, which requests are excluded.
- Is measured close to the user: at the load balancer or the client where practical, so failures before the application are counted.
- Covers the journeys that matter most: one SLI per critical user journey is better than dozens of indicators nobody reviews.
- Has enough traffic to be meaningful: at very low volume, a single failure can swing the percentage sharply.
Where should an SLI be measured?
| Source | Strength | Limitation |
|---|---|---|
| Application metrics and logs | Detailed, easy to add per endpoint | Misses requests that fail before reaching the application |
| Load balancer or API gateway | Sees every request, close to the user | Cannot tell if a successful response had the right content |
| Synthetic checks | Works even with no real traffic | Measures a scripted path, not real users |
| Client-side measurement | Closest to what users experience | Noisy, affected by user devices and networks |
Many teams start with load balancer or gateway metrics for availability and latency, then add application-level checks for correctness.
SLI examples by service
| Service | Example SLI |
|---|---|
| Payment API | Percentage of valid payment requests that complete successfully |
| Dispatch API | Percentage of valid dispatch requests that assign a delivery partner |
| Login service | Percentage of valid sign-in attempts that succeed in under 1 second |
| Search | Percentage of search requests that complete in under 500 ms |
| Data pipeline | Percentage of records available to downstream systems within 5 minutes |
Common mistakes when defining SLIs
1. Measuring infrastructure health instead of user experience
CPU, memory and host uptime explain why a service is struggling, but they are not SLIs. An SLI should count outcomes users see.
2. Using averages for latency
An average response time of 200 ms can hide 5% of requests taking several seconds. Count the share of requests under a threshold instead.
3. Counting the wrong events as valid
Health checks inflate the SLI, and requests rejected because of bad client input are usually not the service’s failures. Decide which events are valid before setting a target.
4. Defining too many SLIs
A handful of SLIs tied to critical user journeys gets reviewed and acted on. Dozens of indicators become another dashboard.
Frequently asked questions about SLIs
What is an SLI in simple terms?
An SLI is a measurement of how well a service is working for its users, such as the percentage of requests that succeed or the percentage served in under 300 ms.
What is an example of an SLI?
If an API receives 100,000 valid requests and 99,950 succeed, its request-success SLI is 99.95%. Latency, correctness and freshness can be measured the same way, as good events divided by valid events.
What is the difference between an SLI and an SLO?
An SLI is the measurement; an SLO is the target for that measurement over a window. A 99.95% success rate is an SLI. “99.9% of requests succeed over 30 days” is an SLO.
Is uptime a good SLI?
Host or server uptime is usually not a good SLI, because a service can be up while users see errors or slow responses. The share of user requests that succeed is a better measure of availability.
How many SLIs should a service have?
Most services need only a few: often one availability and one latency SLI for each critical user journey, with correctness or freshness added where they matter.
Should 4xx errors count against an SLI?
Usually not. Most 4xx responses are caused by the client, such as an invalid request, and are excluded from valid events. Some, such as 429 rate-limit responses caused by the service’s own capacity, may count as failures. Define this explicitly.
Key takeaways
- An SLI measures how a service is performing for its users.
- Most SLIs are good events divided by valid events, as a percentage.
- The four common types are availability, latency, correctness and freshness.
- A good SLI counts outcomes users notice, not infrastructure health.
- An SLI only becomes actionable once an SLO sets a target for it.