“Be more reliable” isn’t an engineering target — it doesn’t say how reliable, measured how, or what to do when you fall short. SLIs, SLOs, and error budgets are the vocabulary Google’s Site Reliability Engineering (SRE) discipline developed to turn reliability into something concrete enough to actually engineer against.

SLI: a measured signal

A service level indicator (SLI) is a specific, quantitative measurement of some aspect of the service’s behavior — the proportion of requests that succeed, the latency of the 95th-percentile request, the proportion of a batch job’s results that are correct. An SLI is just a number derived from real telemetry: logs, metrics, or traces, aggregated into a single meaningful measurement. On its own, an SLI doesn’t say whether that number is good or bad — it’s the raw material the next two concepts are built from.

SLO: a target for that signal

A service level objective (SLO) is a target value or range for an SLI, over a defined time window — for example, “99.9% of requests succeed, measured over a rolling 30 days.” Google’s SRE book devotes a full chapter to service level objectives, and one of its central points is that SLOs should be set deliberately, based on what users actually need and notice, rather than defaulting to the highest number that sounds impressive. A target of 99.999% (“five nines”) sounds better than 99.9%, but the cost and engineering effort to close that gap is enormous, and it’s wasted effort if users can’t actually perceive the difference.

Error budget: the allowance implied by the target

An error budget falls directly out of the SLO: if the target is 99.9% success, the error budget is the remaining 0.1% — the amount of failure the system is allowed to have, over the measurement window, before it’s out of compliance with its own target. Framed as a budget rather than a violation, this becomes a genuinely useful operational tool: as long as budget remains, the team has room to take reasonable risks — ship faster, run more experiments, defer some hardening work. Once the budget is exhausted, the SRE model’s usual response is to shift priority toward reliability work — slow down releases, invest in the fixes needed to stop burning budget — until the system is back within target.

This is what makes error budgets more useful than a simple uptime target: an uptime number alone doesn’t tell you what to do differently, while a depleted error budget gives a concrete, pre-agreed trigger for changing behavior, rather than a debate that has to happen from scratch during every incident review.

SLO versus SLA: internal target versus external promise

A service level agreement (SLA) is a different thing, though related: an SLA is an external, often contractual, commitment to customers, typically with defined consequences (service credits, for example) if it’s breached. SLOs are usually set stricter than any corresponding SLA, specifically so that the team has warning and time to respond before an internal target slip becomes an external, contractual failure. Conflating the two — treating your internal SLO as if it were the customer-facing SLA — tends to produce either an SLA that’s too loose to mean anything, or an SLO with no working margin left to actually manage against.

Why this needs good observability and honest architecture

None of this works without reliable telemetry to measure the underlying SLI accurately in the first place — an SLO is only as trustworthy as the data it’s computed from. It also can’t promise more than the underlying architecture supports: an availability SLO that assumes multi-zone resilience isn’t achievable if the system is actually deployed to a single availability zone, a constraint covered in Regions, Availability Zones, and Why Cloud Architecture Is Geographic. When something does push the system outside its error budget, how the team actually responds is covered in How On-Call and Incident Response Actually Work.

Key takeaway

SLIs measure what’s actually happening, SLOs define what “good enough” means for that measurement, and error budgets translate the gap between an SLO and perfection into a concrete, pre-agreed amount of acceptable risk — one that’s meant to actively shift priorities once it’s spent, rather than sitting as an abstract number nobody acts on.

This article explains general SRE concepts; specific targets and processes should be adapted to your system and organization. See our disclaimer.