SRE Fundamentals: SLIs, SLOs, and Error Budgets

Site Reliability Engineering (SRE) is the discipline Google formalized and popularized through its SRE book, which describes applying software engineering approaches to operations problems. Its core contribution to observability practice is a precise, shared vocabulary for reliability: instead of vaguely wanting a service to be “healthy,” SRE defines exactly what is measured, what target that measurement must meet, and how much failure is acceptable before that failure becomes an active decision-making input. That vocabulary is SLI, SLO, and error budget, and it’s what turns the metrics, traces, and logs a team already collects into something an organization can actually govern by.

An SLI (service level indicator) is a specific, quantitative measurement of some aspect of the service — request latency, error rate, or availability are the most common. An SLO (service level objective) is a target value or range for that SLI over a defined window — for example, “99.9% of requests complete successfully over a rolling 30 days.” An error budget is simply what’s left over: 100% minus the SLO, expressed as the amount of unreliability the service is allowed to have. A 99.9% SLO leaves a 0.1% error budget; how a team spends that budget — on releases, on experiments, on accepted risk — is where SRE practice becomes operational rather than theoretical.

Why it matters

• SLIs turn the four pillars into a single number stakeholders can reason about. Metrics, traces, and logs all continuously bombard a team with signal; an SLI picks the handful that actually reflect user-facing service quality and discards the rest as diagnostic detail rather than a target.
• SLOs replace vague reliability goals with a negotiated, explicit target. “Make it fast and reliable” isn’t actionable; “99.9% of requests under 300ms over 30 days” is something engineering and product can jointly own and trade off against feature velocity.
• Error budgets give teams a shared, objective way to decide when to slow down. Rather than an ad hoc argument about whether a risky release should ship, the error budget converts that into a data-driven check: if the budget is exhausted, the answer is already no until reliability recovers.
• They connect directly to alerting and incident response. SLO burn — the rate at which a service is consuming its error budget — is one of the most reliable signals for deciding what deserves to page a human versus what can wait for business hours.

How to approach it

• Pick SLIs that reflect what users actually experience, not what’s easy to measure. Request success rate and latency percentiles (p50, p95, p99) measured at the edge of the system are usually better SLIs than internal component health, because they reflect the thing users actually feel.
• Set SLOs slightly below what the system can currently achieve, and revisit them. An SLO set at exactly current performance leaves no room for normal variance; an SLO set unrealistically high (99.999% for a service that has never hit that) makes the error budget meaningless. Review and adjust SLOs as the system and its usage change.
• Define the error budget policy before you need it. Decide in advance what happens when the budget is exhausted — freezing non-essential releases, requiring extra review, or shifting engineering focus to reliability work — so it’s a pre-agreed process during an incident, not a real-time argument.
• Track burn rate, not just budget remaining. A service that has used 10% of its monthly error budget in the first hour of the month is in a very different situation than one that used 10% steadily over three weeks; multi-window burn-rate alerts (fast burn over a short window plus a slower confirming window) are standard practice for catching this early.
• Instrument SLIs directly rather than deriving them after the fact. Recording rules or dashboards purpose-built to compute an SLI continuously (in Prometheus, Grafana, or a commercial APM’s SLO feature) keep the calculation consistent and queryable, rather than reconstructing it manually during a postmortem.

SLOs and error budgets are the connective tissue between raw observability data and the practices that use it operationally — most directly, alerting and incident response, and release-gating decisions.