We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningAdvanced · Reliability & Resilience
Service Level Indicator: a quantitative measure of service behavior, like the proportion of requests faster than 300ms. The raw metric that feeds SLOs.
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.
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.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers SLI across a run of lessons, not one page. These 4 alone are about 62 minutes of step-by-step reading, every one with a quiz.
The specific measurements that tell you whether your service is healthy, the numbers behind your promises.
Putting it all together, how SLIs, SLOs, and SLAs work as a unified reliability framework.
Windows that slide with every event, continuous recalculation over the most recent N events or T time.
Rate limit with a moving time window, smoother than fixed windows and more accurate.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with SLI (Service Level Indicators)pay once,
yours for life
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.
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 a target that 99 percent of requests are served in under 300ms, which is the same as saying the 99th percentile latency is under 300ms.
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.
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.
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.
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.
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.
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.
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.
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.
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.
SLA/SLO/SLI Overview
Putting it all together, how SLIs, SLOs, and SLAs work as a unified reliability framework
Sliding Windows
Windows that slide with every event, continuous recalculation over the most recent N events or T time
Sliding Window
Rate limit with a moving time window, smoother than fixed windows and more accurate
Routing Slip
Attach a travel itinerary to the message itself, each service processes it and forwards to the next stop
Where Prompts Slip: The Same House Rules for Four Models, Checked Field by Field
I gave four prompted models, from 3B to 14B, the full house rules for the ticket task and a JSON schema, and scored every field of every reply on the 140 test messages. Every reply was valid JSON and the order number was right almost every time, but the whole ticket was right on only 50 to 93 of 131 fully gold messages. Reading every wrong answer shows which rules slip: a bigger model fixed extra words in the item and questions read as requests, but not comments that ask for nothing, which even qwen2.5:14b got wrong 11 times out of 13. Twenty-two fields were wrong in all four models. Those are the first thing a fine-tune has to beat.
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.
This page explains the idea. The "SLI (Service Level Indicators)" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the SLI (Service Level Indicators) lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about SLI in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
