Service Level Indicator

What is Service Level Indicator?

A Service Level Indicator (SLI) is a number that tells you how a service is actually behaving. It comes from the telemetry your monitoring and observability tools already collect.

Each SLI tracks one slice of service health. That might be availability, response latency, or the rate of failed requests, and it gets reported as a figure you can watch move from week to week. Put simply, an SLI answers a narrow question: right now, is the service doing what users expect of it?

Say a checkout API handled 99.7% of requests successfully in the last hour, and 96% of those responses came back under 200 milliseconds. Both figures describe what happened. Neither is a target, and neither is a promise to a customer.

One detail matters early. Most SLIs are written as a ratio of good events to total valid events, which is what makes them easy to compare against a goal and easy to carry from one service to the next.

How is a Service Level Indicator Measured?

Measuring an SLI comes down to counting. You count the events that clear a defined quality bar, then divide by every event that had a fair chance of clearing it. The result is a percentage, read over whatever time window you pick.

1. Define the Good Event

A good event is any request or operation that meets the condition you are measuring. For an availability SLI, that means a response that came back successfully. For a latency SLI, it means a request that finished inside the threshold the team agreed on, say 300 milliseconds.

2. Count Total Valid Events

The denominator is every event that should count, once you strip out the traffic that should not. Health checks, synthetic probes, internal test calls: none of those reflect user activity, so they get filtered before the math happens. What remains is the traffic that maps to genuine user experience.

3. Calculate the Ratio

Divide the good events by the valid total, and you have your SLI. Out of 50,000 requests, 49,850 succeeded, which works out to an availability SLI of 99.7%. The arithmetic is plain. The discipline is in defining good and valid before you start.

What is the Difference Between SLI, SLO, and SLA?

These three acronyms travel together, and people mix them up constantly. Each one answers a different question about reliability.

1. Service Level Indicator (SLI)

The SLI is the measurement. It records what is happening from live data, things like uptime, p95 latency, or error rate.

2. Service Level Objective (SLO)

The SLO is the target you set for that measurement. It says where the SLI needs to land, for instance, 99.9% availability across a rolling 30 days.

3. Service Level Agreement (SLA)

The SLA is the promise you make to a customer in writing, usually with service credits or penalties attached if you miss it. Smart teams set the SLA a notch below the SLO on purpose. That gap is the cushion that keeps an internal miss from turning into a contractual one.

The short version: the SLI is the reading, the SLO is the goal you hold it to, and the SLA is what you owe the customer if you fall short.

What are Common Examples of SLIs?

Which SLIs you pick depends on what your users care about most. A handful of categories show up in nearly every reliability program, and if you have seen the golden signals from site reliability engineering, you will recognize most of this list.

1. Availability

Availability tracks the share of requests the service handled successfully. A web app might post 99.8% over a week. That sounds airtight until you count what 0.2% means at scale, which is why even small dips here get attention.

2. Latency

Latency tracks how fast the service responds. Teams rarely average it, because an average hides the slow tail. Instead they measure a percentile, for example 95% of requests finishing under 300 milliseconds, so the worst experiences still show up in the number.

3. Error Rate

Error rate is the share of requests that came back as failures. On a payment flow the bar is strict, often under 0.2% a month, because a failed transaction is money and trust gone at once. Lower-stakes internal tools can usually tolerate more.

4. Throughput

Throughput counts how much work the service clears in a window, often requests per second. It is less about user-facing quality and more about whether the system keeps pace with demand before queues back up and everything else starts to slip.

How Do SLIs Work in Practice?

On the ground, an SLI is how raw telemetry becomes a signal someone can act on.

It starts with a choice. You decide which indicators best stand in for user experience, then instrument the service so those events stream in without anyone babysitting them. From there, your monitoring stack computes the ratio over a rolling window and keeps it current.

Take a checkout service tracked through two SLIs at once, availability and latency. Availability holds steady at 99.9%, but latency slips to 90% of requests under the threshold. The service is up, yet it feels sluggish, and the latency SLI is the thing that caught it.

Then comes the comparison. Each SLI gets measured against its SLO, and when an indicator drifts toward the line or crosses it, that is the cue for an alert, an investigation, or a reshuffle of priorities. The point is to move before users feel the problem, not after.

Why are Service Level Indicators Important?

SLIs matter because they replace argument with evidence. Reliability stops being a question of who feels strongest in the room and starts being a number everyone can see.

1. Grounded in User Experience

A good SLI tracks what users feel, not what is convenient to graph. Whether a page loads, whether a request goes through: that is the territory worth measuring. Spend the effort there, and engineering work stays pointed at outcomes customers notice instead of dashboards they never open.

2. A Basis for SLOs and Error Budgets

Every SLO and every error budget is built on top of an SLI. Get the measurement wrong and the target underneath it means nothing, because you are now holding the service to a figure that does not describe reality. The SLI has to be sound first. Everything reliability-related sits on it.

3. Faster Detection of Problems

Because an SLI runs continuously, it shows quality slipping while it is still slipping, not after the fact. A falling indicator is an early warning. Teams that watch it can step in before the support queue fills with the same complaint.

4. Shared Language Across Teams

SLIs hand engineering, operations, and the business one set of numbers to argue from. When everyone points at the same figure, the conversation about reliability versus speed gets a lot less circular.

What Are SLI Best Practices?

A strong SLI is accurate and close to the user. The teams that get the most out of SLIs also keep the list short and the definitions tight.

1. Measure What Users Feel

Point the SLI at the user, not the server room. CPU and memory counters have their place, but a user has never once cared about your CPU graph. They care whether the request went through and how long it took. Measure that.

2. Keep the Set Small

Fewer SLIs beat more of them. A short, sharp list is something a team can act on at 2 a.m.; a sprawling one just buries the signal that matters under the ones that do not. When an incident hits, you want three numbers you trust, not thirty you half-remember.

3. Define Good and Valid Clearly

Write down what counts as good and what counts as valid before you measure anything. It feels like busywork. It is not. Those two definitions are the whole foundation, and when they live only in someone's head, the SLI quietly drifts every time the team or the service changes.

4. Review as the Service Changes

Services do not hold still. Traffic shifts, dependencies change, and yesterday's reasonable threshold turns into today's false alarm. Put a recurring review on the calendar and retune the SLIs that no longer match how the service runs now.