SLI
Service Level Indicator: a quantitative measure of service behavior, like the proportion of requests faster than 300ms. The raw metric that feeds SLOs.
What is SLI?
In short
A Service Level Indicator (SLI) is a number that measures one specific aspect of how a service behaves for users, expressed as a ratio of good events to total events, such as the percentage of requests that returned successfully or finished in under 300ms. It is the raw, measured signal that Service Level Objectives (SLOs) and Service Level Agreements (SLAs) are built on top of.
What an SLI Actually Is
An SLI is a quantitative measure of some dimension of your service that users care about. The most useful form is a ratio: good events divided by total events, times 100. For example, out of 1,000,000 HTTP requests in the last hour, 999,200 returned a non-5xx status. That gives an availability SLI of 99.92 percent.
The reason teams favor the good-over-total ratio is that it produces a clean number between 0 and 100 that is easy to reason about and easy to set a target against. A raw count like 800 errors per hour means nothing without traffic context. The same 800 errors out of 1,000 requests is a disaster, while 800 out of 10,000,000 is noise.
The four SLIs you see most often are availability (fraction of successful requests), latency (fraction of requests faster than some threshold), throughput, and error rate. The phrase popularized by Google's Site Reliability Engineering book groups these as the golden signals: latency, traffic, errors, and saturation.
How an SLI Is Measured Under the Hood
Every SLI needs three precise definitions: what counts as an event, what makes an event good, and where you measure it. Getting these wrong is the most common SLI mistake. If you define a latency SLI as requests under 300ms but measure at the application server, you miss the time spent in the load balancer and the client network, so your number lies to you.
You typically measure at the point closest to the user that you control, which is usually the load balancer or API gateway. Cloudflare, AWS Application Load Balancer, and Envoy all emit per-request logs with status codes and latency that you aggregate into SLIs. Latency SLIs are almost always expressed as a percentile threshold, not an average, because averages hide tail pain. A common pattern is the proportion of requests served in under 300ms at the 99th percentile.
The aggregation happens over a rolling window, often 28 days. A monitoring system like Prometheus computes the ratio with a query that divides a counter of good requests by a counter of total requests over that window. The output is a single percentage that you can chart, alert on, and compare against your SLO target.
When to Use SLIs and the Trade-Offs
Use SLIs to define what reliability means in numbers before you promise anything to users or set internal goals. An SLO is a target for an SLI, and an SLA is a contract with financial penalties built on an SLO. You cannot have any of the upper layers without first picking the right indicator, so the SLI is the foundation.
The main trade-off is picking too many SLIs. If you track 40 indicators, every one of them is occasionally red and the team stops trusting them. Pick a small set, usually two to four per service, that genuinely reflect user happiness. A request that succeeds but takes 8 seconds is not a good event, so availability alone is not enough; you almost always pair it with latency.
The other trap is measuring what is easy instead of what matters. CPU utilization is trivial to graph but no user has ever filed a ticket about your CPU. They file tickets when the page is slow or the checkout button fails. Good SLIs track the user-visible symptom, not the internal cause.
A Concrete Example
Imagine a payments API. The team defines two SLIs. The availability SLI counts every request to /charge, and a good event is any response with status code under 500 returned within the timeout. The latency SLI counts the same requests, and a good event is one served in under 400ms.
Over a 28-day window the API serves 50,000,000 requests. 49,975,000 return without a server error, giving an availability SLI of 99.95 percent. Of those, 49,500,000 finish under 400ms, giving a latency SLI of 99.0 percent.
These two numbers now drive everything downstream. The team sets an availability SLO of 99.9 percent, which means they have an error budget of 0.1 percent, or 50,000 failed requests in the window. As long as the SLI stays above the SLO, they ship features fast. When the SLI drops near the SLO line, the error budget is nearly spent and they freeze risky deploys until reliability recovers.
Where it is used in production
Coined the SLI/SLO/SLA framework in its Site Reliability Engineering practice and tracks golden-signal SLIs for services like Search and Gmail.
Prometheus
The open-source metrics engine most teams use to compute availability and latency SLIs as good-over-total ratios over rolling windows.
Datadog
Offers a built-in SLO product where you define SLIs from monitors or metrics and watch error budget burn in real time.
Amazon CloudWatch
Emits per-request latency and error metrics from ALB and API Gateway that AWS customers aggregate into availability and latency SLIs.
Frequently asked questions
- What is the difference between an SLI, an SLO, and an SLA?
- An SLI is the measured number, like 99.95 percent of requests succeeding. An SLO is the target you set for that number, like 99.9 percent. An SLA is a contract with a customer that promises a number and pays penalties if you miss it. The SLI feeds the SLO, and the SLO usually sits a bit above the SLA so you have a safety margin.
- How is an SLI calculated?
- The standard form is good events divided by total events, times 100, over a fixed window. For availability that is successful requests over all requests. For latency it is requests faster than a chosen threshold over all requests. You measure at the point closest to the user that you control, usually the load balancer.
- Why use a percentile for latency SLIs instead of an average?
- Averages hide the slowest requests. If most requests take 50ms but 1 percent take 5 seconds, the average still looks fine while a real slice of users suffers. A 99th percentile threshold, such as the fraction of requests under 300ms at p99, exposes that tail and tracks the experience of your worst-served users.
- How many SLIs should a service have?
- Usually two to four. Availability and latency cover most services. Adding too many indicators means several are always partly red, the team stops trusting them, and the signal gets diluted. Pick the small set that genuinely reflects whether users are happy.
- Is CPU utilization a good SLI?
- No. CPU is a cause metric, not a user-visible symptom. Users never complain about your CPU; they complain when pages are slow or requests fail. A good SLI measures the symptom the user feels, such as request success rate or response time, and CPU belongs in saturation alerts instead.
Learn SLI hands-on
This page explains the idea. The full lesson lets you step through the ring as servers join and leave, read the implementation, and check yourself with a quiz. It is one of 760+ lessons in the System Design Masterclass, from your first API call to distributed consensus. Eleven Foundation lessons are free, no signup. Lifetime access is ₹499 in India or $7.99 worldwide, one payment, no subscription.
Related lessons
Lessons that touch on SLI as part of a larger topic.
SLI (Service Level Indicators)
The specific measurements that tell you whether your service is healthy, the numbers behind your promises
intermediate · observability monitoring
SLA/SLO/SLI Overview
Putting it all together, how SLIs, SLOs, and SLAs work as a unified reliability framework
intermediate · observability monitoring
Sliding Windows
Windows that slide with every event, continuous recalculation over the most recent N events or T time
advanced · stream batch processing
Sliding Window
Rate limit with a moving time window, smoother than fixed windows and more accurate
intermediate · api design protocols
Routing Slip
Attach a travel itinerary to the message itself, each service processes it and forwards to the next stop
intermediate · messaging event systems
See also
Related glossary terms you might want to look up next.
SLO
Service Level Objective: a target value for an SLI, like '99.9% of requests under 300ms.' The internal engineering goal that drives reliability investment.
SLA
Service Level Agreement: a contractual commitment between provider and customer specifying uptime, response time, and penalties for breaches. The business version of an SLO.
Metrics
Numerical measurements collected over time that describe system behavior: request rate, error rate, latency percentiles, CPU utilization. Prometheus is the standard collector.
Chaos Engineering
Deliberately injecting failures into a system to test its resilience. Netflix's Chaos Monkey randomly kills servers to ensure the system survives.
Back Pressure
A flow control mechanism where a slow consumer signals upstream producers to slow down. Prevents systems from being overwhelmed by data they can't process.
Error Budget
The allowed amount of unreliability derived from SLOs. If your SLO is 99.9% uptime, your error budget is 0.1% (about 43 minutes/month). Once exhausted, freeze deployments.