Service Level Indicators: SLIs Explained

Every reliability conversation you have starts with a number both sides trust. Your service level indicator (SLI) gives that conversation a number that measures what users experience, as Google’s Anatomy of an Incident report defines an SLI. Every target, alert, and error budget you build on it inherits that credibility.

This guide covers the main SLI types for each kind of service, how to calculate SLI metrics from good and total events, how service level indicators and objectives connect to agreements and error budgets, and how to choose and implement SLIs in production.

What Is a Service Level Indicator?

Google’s SRE book defines an SLI as a carefully defined quantitative measure of some aspect of the service level a service provides. The book gives request latency, error rate, and system throughput as examples. Your pipeline turns raw data from a measurement window into a rate, average, or percentile.

An SLI is the metric you choose because users feel it. Google’s SRE book warns that you “shouldn’t use every metric you can track in your monitoring system as an SLI.” CPU utilization on a database host is a legitimate monitoring metric but a poor SLI because users never see it.

Types of Service Level Indicators

The Implementing SLOs chapter of Google’s SRE workbook recommends “choosing a small number (five or fewer) of SLI types that represent the most critical functionality to your customers.” Its SLI menu groups these types by service. 

Request-driven services track availability, latency, and quality. Pipelines track freshness, correctness, and coverage, and storage systems track durability. Google’s SRE book adds throughput for data processing pipelines, and error rate is the inverse of request-based availability.

Latency: Track the Tail, Not the Mean

Latency is how long a response takes, and the useful SLI is the share of requests faster than a threshold. A 99th or 99.9th percentile shows a plausible worst case the average hides. 

The Implementing SLOs chapter pairs 90 percent of requests under 100 ms with 99 percent under 400 ms, because a single 90 percent threshold would let the remaining 10 percent take 10 seconds.

Error Rate: Failures as a Fraction of All Requests

Error rate is the fraction of requests that fail, which Google’s Alerting on SLOs chapter defines as the ratio of bad events to total events. For a web service, the Implementing SLOs chapter counts HTTP 5xx responses against the SLO, which makes error rate the inverse of the request-based availability SLI described next. 

Five server errors in 1,000 requests is a 0.5 percent error rate. Whether a 429 or a connection timeout also counts belongs in the written SLI specification.

Availability: Request Success Beats Uptime

Availability is either the fraction of time the service was up or the fraction of well-formed requests that succeeded. Request success fits distributed services better because, for example, an hour that fails 5% of operations never registers as “down.” 

For a web service, the availability SLI is non-5xx responses divided by all responses over the window.

Throughput and Freshness: How Pipelines Show Progress

Throughput is the volume of work a service completes, usually requests or records per second. Google’s SRE book says data processing pipelines care about throughput, measured by the number of records processed per second. The Implementing SLOs chapter adds freshness to its pipeline menu, measured as the share of data updated more recently than a time threshold. 

For request/response services, throughput sits beside latency and availability, the per-request signals application performance monitoring tools collect.

Durability: Will the Data Still Be There?

Durability is the likelihood that stored data survives over a long period. Amazon S3 is designed to exceed 99.999999999 percent (11 nines) durability. That vendor design target differs from a measured SLI.

How to Calculate an SLI from Good and Total Events

The Implementing SLOs chapter treats an SLI as “the number of good events divided by the total number of events,” a ratio between zero and 100 percent. Google’s SLO Adoption and Usage report tightens the denominator to SLI = (Good events / valid events) × 100%, which counts only valid requests scoped by attributes such as hostname or request path. An API that serves 10,000 valid requests and succeeds on 9,950 has an SLI of 99.5 percent.

A well-specified SLI names the events and where it measures them. Its scope lists included and excluded attributes, and its good-event definition states what makes an event good.

Exclusions stay few to keep them from quietly hiding budget consumption. Rolling windows track user experience more closely than calendar months, and the Implementing SLOs chapter recommends rolling windows of whole weeks to keep the weekend count constant. Calendar windows align better with business planning.

SLI vs. SLO vs. SLA: How the Three Work Together

A service level objective (SLO) sets a target value or range of values for a service level that an SLI measures. Google’s SRE book defines a service level agreement (SLA) as “an explicit or implicit contract with your users that includes consequences of meeting (or missing) the SLOs they contain,” and without an explicit consequence, “you are almost certainly looking at an SLO.” 

SRE can help define SLIs, but SLA construction belongs to business and product. SLOs should be more restrictive than SLAs so the internal target trips first.

Dimension	SLI	SLO	SLA
What it is	Quantitative measure of one aspect of service level	Target and time window applied to an SLI	Contract with users that attaches consequences to missed SLOs
Who sets it	SRE helps define it	Engineering, product, and SRE together	Business and product, with legal input
Consequence of breach	None on its own, since it’s a measurement	Set by the team’s error budget policy, such as a release freeze	Rebate, penalty, or service credit
Example	Fraction of non-5xx responses over all responses	99.9% of requests succeed over a rolling 28 days	EC2 region-level SLA of 99.99% monthly uptime for instances across two or more Availability Zones, with bill credits for misses

SLI Examples for APIs, Databases, and Streaming Pipelines

Google’s Art of SLOs workshop suggests three to five SLIs per user journey. Its SLI menu suggests availability and latency for request/response journeys.

A web API pairs availability with latency. Okta’s fine-grained authorization service, backed by DynamoDB, targets four nines of availability and p99 latency at or below 50 ms. A database or storage tier adds durability to latency and availability, the signals Google’s SRE book lists for storage systems.

For streaming or queue services, a pipeline pairs a throughput SLI, such as messages processed per second, with freshness, which translates lag into user impact. Google’s Dataflow planning guide suggests the age of the most recently processed user activity as a freshness SLI, and its example treats system latency above four minutes as a missed SLO.

How to Define SLIs That Reflect User Experience

Your SLI needs both a specification and an implementation. The specification states the service outcome users care about without tying it to a measurement method. The implementation starts with the user journey and defines how and where you measure that outcome.

Starting from the Critical User Journey

The Implementing SLOs chapter defines a critical user journey (CUJ) as “a sequence of tasks that is a core part of a given user’s experience and an essential aspect of the service.” SLIs belong to the user journey, and individual microservice metrics belong at a different scope.

Ranking journeys by business impact and mapping each to its few SLIs ties every SLI to something a user notices when it breaks. Internal hops users never perceive, such as a cache warm-up, stay off the SLI list.

Metrics Users Can Feel

Google’s Art of SLOs workshop has participants choose SLI specifications for each user journey, with reliability shared between developers and operations. Request success rate and latency at the user boundary pass that test. 

Google’s SLO Adoption and Usage report warns against relying on CPU or memory metrics, since users don’t care about them as long as the service works.

Defining “Good” Before Measuring

Your SLI needs an event, a success criterion, and a record of where and how you capture success or failure, and the SLO then sets the target and window. Define the SLI before baselining the system, then set the SLO from the baseline. Your team documents any later change to the “good” threshold.

Where SLI Definitions Go Wrong

Too many SLIs per journey can spread your attention until individual signals no longer drive decisions, and Google’s Art of SLOs workshop keeps the set to a handful per journey. 

Vanity metrics that look good and say nothing about users are another failure mode. Setting your first SLO at an ambitious target because it sounds right is a third, and Google’s SLO Adoption and Usage report expects aspirational SLOs to be missed at first and redefined as data arrives.

How SLIs Feed the Error Budget

An error budget is 1 minus the SLO, so the example SLO in the table (%99.9) has a 0.1 percent budget. 

The Implementing SLOs chapter shows a service that receives three million requests over four weeks with a budget of 3,000 failed requests, and a single outage that causes 1,500 errors spends half of it. A complete outage would spend the same 0.1 percent in about 40 minutes of a 28-day window. Every bad event in the SLI ratio draws down the budget.

A constant error rate equal to the budget’s allowed fraction burns the whole budget by the end of the window, which Google’s Alerting on SLOs chapter calls a burn rate of 1. Burn-rate alerts fire when consumption outpaces that rate, and the chapter credits them with better precision than static error-rate alerts, which fire on many events that never threaten the SLO and feed alert fatigue. 

For a 99.9 percent SLO, the chapter recommends paging at a burn rate of 14.4 over one hour or 6 over six hours, and opening a ticket at a burn rate of 1 over three days, each paired with a short window one-twelfth as long. 

A sample error budget policy in Google’s SRE workbook halts all changes except P0 issues and security fixes once a service exceeds its budget over the preceding four weeks, and it “is not intended to serve as a punishment for missing SLOs.” The Implementing SLOs chapter adds that larger organizations normally give SLO ownership to the product owner.

Best Practices for Implementing SLIs

Product and engineering teams must agree on SLI definitions before anyone sets a target. The practices below cover where to measure, how to instrument, and how to set and maintain targets:

• Measure at the load balancer or client: The Implementing SLOs chapter recommends measuring success and latency at the load balancer or on the client. Server-side metrics miss requests that fail before they reach your code.
• Standardize server-side measurement with OTel: OpenTelemetry (OTel) instrumentation records the http.server.request.duration histogram, which the OTel HTTP metrics spec defines in seconds with http.response.status_code and http.route as attributes. One instrument yields both the latency SLI (requests under a threshold bucket over all requests) and the error-rate SLI (5xx over all).
• Put a bucket boundary at your latency threshold: An exact latency ratio needs a bucket boundary at your threshold, and the spec’s default boundaries jump from 250 ms to 500 ms. Prometheus classic histograms estimate any percentile that falls between boundaries.
• Set the lowest target the service can get away with: Google Cloud’s SRE fundamentals post advises setting each SLO at the lowest level of reliability the service can get away with. The Implementing SLOs chapter calls a four-week rolling window a good general-purpose interval.
• Confirm each window has enough events: Coralogix’s SLO best practices note that a 99.9 percent target needs more than 1,000 events per window to survive a single bad event. A new SLO isn’t reliable until one full window has passed.
• Review SLOs on a schedule: SLIs go stale as architectures and user expectations change. Teams review their SLOs monthly at first and quarterly once they settle, checking them against user happiness signals such as support tickets.

These practices keep your SLIs tied to what users experience as traffic, architecture, and targets change.

Why the Right SLIs Come Before SLOs and SLAs

An SLA built on an SLI nobody tied to a user journey is a contract with no instrument behind it. Teams that start from CUJs end up with a handful of SLIs, each of which can name the user who gets hurt when it drops.

Coralogix’s SLO tracking covers event-based, time window-based, and application performance monitoring (APM) SLOs. The SLO Center groups SLOs by bounded labels such as cluster or namespace, and Coralogix’s SLO best practices recommend a separate filtered SLO for each high-value customer. 

Burn-rate alerts in Coralogix run in single or dual mode, and dual mode adds a fixed 10-minute check for sudden drops in service quality. SLO Center gives you one place to manage all your objectives, and SLO coverage is one of the markers in Coralogix’s observability maturity model.

You can try a CUJ-based SLO with burn-rate alerts on a free 14-day Coralogix trial. Your trial lets you track the user-facing signals behind your targets.

Frequently Asked Questions About Service Level Indicators

What is the difference between SLA, SLO, and SLI?

An SLI is the measurement itself, such as this week’s share of non-5xx responses. An SLO is the target for that measurement over a rolling window. An SLA is the contract, usually backed by a service credit, and it sits looser than the internal SLO.

What is an example of an SLI?

An example of an SLI is request success rate, which divides successful requests by all valid requests over the window. A latency SLI divides requests served under a defined latency threshold by all requests. Storage services also track durability, the odds that stored data survives over a given period. Each measures a service outcome users experience.

How many SLIs should a service have?

Your service should start with a small set of SLIs per user journey, drawn from the types that represent its critical functionality. Too many signals can spread your attention and make decisions harder. You can start with availability and latency and add freshness for pipelines.

How do SLIs differ from key performance indicators?

A key performance indicator (KPI) is a business metric such as revenue or conversion rate. Weekly active users is another example. An SLI is a narrow technical measure of a single user-facing behavior, such as the share of checkout requests that complete under 500 ms. The two connect through user happiness, since an SLI below target signals unhappy users, and that tends to hit business metrics.