SLI, SLO, and SLA Explained

A Service Level Indicator is a precisely defined, measured ratio: good events divided by valid events, over some window. "Proportion of HTTP requests that returned a non-5xx status within 300ms, out of all requests excluding health checks" is an SLI; "the API is fast" is not, because nothing about it is measured or falsifiable. Common SLIs are request success ratio, a latency percentile against a threshold, and (for pipelines) proportion of records processed within a freshness window.

The precision matters because every later number — the SLO target, the error budget, the alert threshold — is built directly on top of exactly how the SLI is defined. Change what counts as a "valid" request (excluding retries, excluding a specific low-traffic endpoint) and every number downstream silently means something different, even if the SLO percentage itself never changes.

A Service Level Objective is an internal target for an SLI over a time window — "99.9% of requests succeed over a rolling 30 days." It's the number engineering holds itself to, drives alerting off of, and uses to decide whether to ship a risky change this week. A Service Level Agreement is an external, often contractual promise to customers, typically with a defined remedy (service credits, refunds) if breached.

The SLA is deliberately set looser than the SLO — a common pattern is an SLO of 99.9% paired with an SLA of 99.5%. That gap is a buffer: the internal target is designed to catch a reliability problem and trigger a response before the looser, customer-facing contractual promise is ever at risk. If your SLO and SLA were the same number, you'd have zero warning between "we're trending toward missing our own internal goal" and "we owe customers a contractual remedy." Setting them equal isn't stricter — it just deletes your own early-warning system.

An error budget is simply 1 - SLO target, converted into concrete terms: a 99.9% SLO over 30 days leaves a 0.1% error budget, which works out to roughly 43 minutes of acceptable downtime (or equivalent failed requests) for that entire month. That budget is a resource a team can deliberately spend — shipping a riskier change, running a chaotic load test in production, taking a planned maintenance window — as long as the spend fits inside what's left.

The operational payoff is that error budgets turn "reliability vs feature velocity" from a recurring argument into a quantified, pre-agreed trade-off: while budget remains, ship at normal velocity; once it's exhausted for the current window, the team's default shifts to freezing new feature launches and prioritizing reliability work until the budget recovers. Nobody needs to personally decide whether the current risk is acceptable — the budget already encodes that decision in advance.

A naive alert ("page if error rate exceeds 1% for 5 minutes") either fires on harmless short blips or misses a real problem that's slower and steadier than its threshold. Burn rate reframes this around the budget itself: a burn rate of 1x means the current error rate would exhaust the entire window's budget exactly by the end of the window if it continued unchanged; a burn rate of 10x means the same budget would be gone in a tenth of the time.

Multi-window, multi-burn-rate alerting (from Google's SRE practice) checks a fast burn over a short window (catching a severe incident within minutes) and a slow burn over a longer window (catching a steady, less dramatic degradation that a short window alone would miss or that would otherwise page too often on noise) simultaneously. A common pairing: page immediately if the 1-hour window shows a burn rate that would exhaust the 30-day budget in about 2 days, and separately page (at lower urgency) if a 6-hour window shows a burn rate that would exhaust it in about a week — catching both the dramatic and the slow-boil failure, each without needing the other window's threshold to be tripped.