What Is a Service Level Indicator (SLI)?

Last verified on Nov 8, 2026.

An SLI is a number you can compute from data you already have, chosen because it tracks something users would complain about. It is the measurement half of a reliability target. The target half is the SLO.

Definition

The SRE book defines a service level indicator as a carefully defined quantitative measure of some aspect of the level of service provided. It lists request latency, error rate, system throughput, and availability as typical examples.

Google's workbook narrows that advice to one form: the SLI should be a ratio of good events to total events. Events here are whatever your service handles, such as HTTP requests, gRPC calls, queue messages, or batch records.

SLI = good events / valid events

This gives a scale from 0% to 100%, where 0% means nothing works and 100% means nothing is broken. It also makes every SLI look the same to your alerting and reporting code: a numerator, a denominator, and a threshold.

Specification and Implementation

The workbook splits an SLI into two layers, which is a useful habit when writing your first ones:

• Specification: what outcome matters to users, independent of how you measure it. "Home page requests that load quickly."
• Implementation: the specification plus a measurement method. "Requests for the home page that the load balancer answered under 400 ms, from the load balancer's logs."

One specification can have several implementations. They differ in quality (how well they capture what users feel), coverage (how many users they see), and cost. A server-side log misses requests that never reached the server. A client-side probe sees them, but samples fewer users.

Which SLI for Which System

The SRE book groups SLIs by system type:

Most teams start with availability and latency, which cover the cases users notice first.

Computing SLIs from Request Logs

If your access logs carry a status and a duration, the numerator and denominator are one query away. The FILTER clause of a PostgreSQL aggregate keeps both counts in a single pass. This example assumes a table request_logs(ts, route, status, duration_ms):

-- Availability SLI per day, ignoring client mistakes (4xx) as invalid events
SELECT date_trunc('day', ts) AS day,
       count(*) FILTER (WHERE status < 400)::float
         / NULLIF(count(*) FILTER (WHERE status < 400 OR status >= 500), 0) AS availability_sli
FROM request_logs
WHERE route = '/checkout'
  AND ts >= now() - interval '28 days'
GROUP BY 1
ORDER BY 1;

-- Latency SLI: share of successful requests served in under 300 ms
SELECT date_trunc('day', ts) AS day,
       count(*) FILTER (WHERE duration_ms < 300 AND status < 500)::float
         / NULLIF(count(*) FILTER (WHERE status < 500), 0) AS fast_sli
FROM request_logs
WHERE route = '/search'
  AND ts >= now() - interval '28 days'
GROUP BY 1
ORDER BY 1;

NULLIF returns NULL instead of failing when a day has no eligible requests, for example when every request was a 4xx. Read a NULL day as "no valid events", not as 0% or 100%.

The status < 400 OR status >= 500 denominator is a choice. It treats a caller's malformed request as outside what you promised. If your clients cannot cause 4xx responses, or a spike in them signals your own bug, count them. See client error spikes for telling the two apart.

Mistakes That Make an SLI Useless

• Measuring a cause, not an outcome. CPU at 80% tells you about a machine. It does not tell you whether a request failed.
• Averages. A mean latency can look healthy while one request in twenty crawls. Use a threshold ratio or a percentile.
• Counting health checks. Probes inflate the good count and hide real traffic. Exclude them in the denominator and numerator.
• Too many SLIs. The SRE book advises choosing a small set. Every extra indicator is one more thing to explain during an incident.

Once the SLI exists, the next step is a target. The SLO page covers that, and the four golden signals are a good checklist of candidates. For the logs behind them, see performance degradation.