SLOs, SLIs, and SLAs: definitions, differences, and worked examples

A service level indicator (SLI) measures how a service is performing, a service level objective (SLO) sets the internal target that measurement must meet, and a service level agreement (SLA) is the external contract that attaches consequences to missing it. Google's Site Reliability Engineering book (2016) formalised the trio, and the arithmetic is strict: a 99.9% SLO over 30 days leaves just 43.2 minutes of downtime.

TL;DR #

• SLI = the measurement (good events ÷ total events, e.g. the fraction of requests served in under 300 ms). SLO = the internal target for that SLI (99.9% over 30 days). SLA = the external contract, with financial penalties.
• Error budget = 1 − SLO. At 99.9% over a 30-day window, that is 43.2 minutes; over an average calendar month, about 43.8. While budget remains, teams ship; when it's spent, releases stop.
• SLAs are deliberately looser than the SLOs behind them, so engineers get paged long before lawyers do.
• More nines get expensive fast: the SRE book notes an incremental reliability improvement "may cost 100x more than the previous increment", while a user on a 99% reliable smartphone cannot tell 99.99% from 99.999%.
• Every SLI is ultimately a query over telemetry: a ratio of good events to total events computed across a time window.

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

An SLI is the measurement, an SLO is the target, and an SLA is the contract. The SLI quantifies one aspect of service level, such as the fraction of requests answered in under 300 ms. The SLO sets an internal target for that SLI, such as 99.9% over 30 days. The SLA attaches external consequences, usually financial, to agreed targets.

Chapter 4 of the Google SRE book defines the layers precisely: an SLI is "a carefully defined quantitative measure of some aspect of the level of service that is provided", an SLO is "a target value or range of values for a service level that is measured by an SLI", and an SLA is "an explicit or implicit contract with your users that includes consequences of meeting (or missing) the SLOs they contain". If there is no explicit consequence for missing the target, you're looking at an SLO, not an SLA.

What is an SLI? #

An SLI, or service level indicator, is a quantitative measure of one aspect of service behaviour, expressed as the ratio of good events to total events over a window. Common SLIs are availability (successful requests ÷ all requests), latency (requests under a threshold ÷ all requests), and quality (undegraded responses ÷ all responses).

The ratio form matters because it makes every SLI read the same way: 100% means everything worked, 0% means nothing did. Google's SRE workbook gives the canonical examples: "number of successful HTTP requests / total HTTP requests" and "number of gRPC calls that completed successfully in < 100 ms / total gRPC requests". Where you measure changes the answer, too: an SLI computed at the load balancer sees failures that a server-side metric never records.

What is an SLO? #

An SLO (service level objective) is a target value for an SLI over a defined window, such as "99.9% of requests succeed over a rolling 30 days". It's an internal engineering commitment whose job is to draw the line between reliable enough and not.

A complete SLO names three things: the SLI it targets, the threshold, and the window. "99.9% availability" is not an SLO until the window is stated, because 99.9% over a day permits 86 seconds of downtime while 99.9% over a quarter permits over two hours in one incident.

What does SLA stand for? #

SLA stands for service level agreement, a contract between a provider and its customers that specifies the service levels promised and the consequences of missing them, typically service credits or refunds. SLAs are negotiated business documents; the SRE book notes that SRE teams typically help define the SLIs inside them but do not set the penalties.

In practice the SLA target sits below the internal SLO. A provider might sign a 99.9% SLA while holding itself to a 99.95% SLO, so the internal alarm fires and the incident is resolved before the contractual threshold is threatened.

What is an error budget? #

An error budget is the amount of unreliability an SLO permits: 1 minus the SLO target. A 99.9% availability SLO leaves a 0.1% error budget. While budget remains, the team ships features; when the budget is exhausted, releases stop and engineering effort shifts to reliability until the budget recovers.

This is the control loop that makes SLOs more than dashboards. Chapter 3 of the SRE book, "Embracing Risk", states it directly: "as long as the uptime measured is above the SLO — in other words, as long as there is error budget remaining — new releases can be pushed". The budget turns a permanent argument between product velocity and stability into arithmetic both sides accept in advance, which is one reason error budgets sit at the centre of site reliability engineering practice.

How do you calculate an error budget? #

Subtract the SLO from 100% to get the budget fraction, then multiply by the window, measured in minutes for a time-based SLO or expected requests for an event-based one.

The request-based version comes straight from the SRE workbook, which frames a 99.9% SLO over 3 million requests as a budget of 3,000 errors. Over a 30-day window, 99% allows 7.2 hours of downtime, 99.5% allows 3.6 hours, 99.9% allows 43.2 minutes, 99.99% allows 4.3 minutes, and 99.999% allows 26 seconds. At four nines and beyond, a single human-paced incident response can consume the entire month's budget.

How do you define SLOs for your service? #

Define SLOs in four steps: pick the user journeys that matter, choose an SLI for each (good events ÷ total events), set a target from measured past performance rather than aspiration, and fix a window (28 or 30 rolling days is the common choice). Start with two or three SLOs.

Three worked examples show the shape:

• Availability SLO: "99.9% of HTTP requests to the checkout API return a non-5xx response, measured at the load balancer over a rolling 30 days." Good events: non-5xx responses. Total: all requests.
• Latency SLO: "99% of successful search requests complete in under 300 ms over a rolling 28 days." Latency SLOs are threshold-counts over the distribution, closely related to percentiles; percentiles vs averages covers why the mean is the wrong instrument here.
• Quality SLO: "99.5% of feed responses are served from the full ranking pipeline rather than the degraded fallback, over 30 days." Quality SLIs catch failures that availability misses: the request succeeded, but the answer was worse.

Targets should trail reality. The SRE workbook's advice is to measure current performance first; a service that historically delivers 99.95% can adopt a 99.9% SLO with headroom, while promising 99.99% from a standing start guarantees a permanently exhausted budget. Instrumenting the four golden signals usually produces the latency and error SLIs for free.

What does an SLI look like as a query? #

Computing an SLI means counting the good events, counting the total, dividing, and comparing with the target. Given one wide event per request, the availability and latency SLIs above reduce to a single aggregation over the window:

This is why SLO practice is inseparable from the observability pipeline underneath it: the SLI is only as trustworthy as the event stream it's computed from, and a 30-day window over a busy service means aggregating billions of rows every time the error budget is checked.

What is a good availability SLO to target? #

For most user-facing services, 99.9% to 99.95% over 30 days is a defensible starting SLO; go higher only when the business case survives the cost. Each additional nine cuts the error budget by 10x while the engineering cost climbs steeply; the SRE book warns an incremental improvement "may cost 100x more than the previous increment".

Two facts cap the useful number of nines. First, users cannot perceive reliability better than the weakest link they reach you through: the SRE book's example is that "a user on a 99% reliable smartphone cannot tell the difference between 99.99% and 99.999% service reliability". Second, your service cannot outperform its critical dependencies; a stack of 99.9% components does not add up to a 99.99% product.

Overshooting has its own failure mode. Google's Chubby lock service was so reliable that teams built unsafe hard dependencies on it, so Google began deliberately taking Chubby down to pull actual availability back to its published SLO. Chubby remains the canonical argument that an SLO is a target, not a floor to be exceeded indefinitely.

Tracking SLOs and error budgets with ClickStack #

ClickStack, the ClickHouse observability stack, stores telemetry as wide events ingested through native OpenTelemetry pipelines, which makes SLI computation the exact query shape shown above: good-event ratios and threshold-counts aggregated over billions of rows in a rolling window. ClickHouse's columnar engine executes those scans fast enough that error-budget burn can be recomputed continuously rather than batched nightly, and HyperDX, the stack's UI, is where teams chart SLIs, set threshold alerts, and drill from a burning budget down to the individual failing requests consuming it. The same discipline applies to the database underneath: teams running ClickHouse Cloud can monitor it against their own reliability targets with clickhousectl.

Computing SLIs over billions of raw events in a rolling window is the query shape ClickStack was built for; it is open source and takes a few minutes to try.