SLOs, SLIs & Error Budgets: Measuring Reliability

Q: What's the difference between an SLI, an SLO, and an SLA?

An SLI is the measurement — a number reflecting service quality from the user's perspective, like the percentage of requests served successfully within 300ms. An SLO is the internal target for that SLI over a window — e.g. 99.9% over 30 days — that your team commits to. An SLA is the external contract with customers promising a (usually looser) level, with financial or contractual consequences if breached. The chain is: SLIs measure, SLOs set the goal you manage to, and SLAs are the customer-facing promise you keep comfortably inside your stricter SLO.

Q: What is an error budget and why is it useful?

An error budget is the allowed amount of unreliability: 100% minus your SLO. A 99.9% monthly SLO gives roughly 43 minutes of permitted failure per month. It's useful because it turns reliability into a spendable currency that resolves the classic tension between shipping features and staying stable: when budget remains, the team can take risks and move fast; when it's exhausted, they pause risky changes and invest in reliability until it recovers. Instead of endless debates between developers and operations, the error budget is the agreed, data-driven policy for that tradeoff.

Q: Why shouldn't I aim for 100% reliability?

Because it's both impossible and the wrong goal. No real system achieves 100% — dependencies, networks, and hardware all fail eventually — and the cost of each additional "nine" of reliability rises roughly tenfold while the user-perceived benefit shrinks toward zero (people genuinely can't distinguish 99.95% from 100%). Chasing perfection diverts huge effort from features users actually want and leaves no error budget to ship with. The right target is the lowest reliability at which users won't notice a difference — enough to keep them happy, not so much that you're spending fortunes on imper

Q: How do SLOs relate to alerting?

SLOs make alerting smarter by tying it to user impact and your error budget rather than raw thresholds. Instead of paging on every CPU spike or transient error, you alert on burn rate — how fast you're consuming the error budget. A fast burn (you'll exhaust the month's budget in hours) warrants an urgent page; a slow burn can be a ticket. This dramatically reduces alert noise and false pages, focusing human attention on problems that actually threaten the reliability target users care about. See Alerting.

SLOs, SLIs & Error Budgets

How reliable should a service be? "As reliable as possible" is the wrong answer — 100% reliability is impossible, infinitely expensive to chase, and usually unnecessary (users can't tell the difference between 99.99% and 100%). SLOs (Service Level Objectives) make reliability a deliberate, measurable target instead of a vague aspiration, and the associated error budget turns the eternal tension between "ship fast" and "stay reliable" into a clear, data-driven decision. This is a cornerstone of Site Reliability Engineering (SRE).

The framework has three linked pieces: an SLI measures something users care about (e.g. the fraction of requests served successfully and quickly), an SLO is the target for that SLI (e.g. 99.9% over 30 days), and the error budget is the allowed shortfall (the 0.1% you're permitted to fail). That budget is the key insight — it gives teams permission to fail a little, and a principled way to decide when to push features versus when to stop and fix reliability.

TL;DR

SLI — a measurement of something users care about (success rate, latency).
SLO — the target for an SLI (e.g. 99.9% of requests succeed over 30 days).
Error budget — the allowed failure (100% − SLO); spend it deliberately.
Reliability is a deliberate target, not "as high as possible" — 100% is the wrong goal.

Quick Example

The three pieces connect into a budget you can spend:

The Three Concepts

SLI (Service Level Indicator) — a quantitative measure of service behavior that reflects user experience: request success rate, latency percentile, availability. Built from metrics. A good SLI rises and falls with how happy users actually are.
SLO (Service Level Objective) — the target value or range for an SLI over a window: "99.9% of requests succeed over 30 days," "p95 latency < 300ms." It's an internal goal the team commits to.
SLA (Service Level Agreement) — a contractual promise to customers, with consequences (refunds) if missed. SLOs are usually stricter than SLAs, giving you a safety margin.

Error Budgets

The error budget is 100% − SLO — the amount of unreliability you're allowed over the window. A 99.9% monthly SLO permits ~43 minutes of failure per month. This number is powerful because it reframes reliability decisions:

Budget remaining → you can take risks: ship features, do migrations, move fast.
Budget exhausted → stop shipping risky changes and invest in reliability until it recovers.

💡 The error budget ends the "devs want to ship, ops want stability" standoff: the budget is the agreed policy. Reliability becomes a shared, measurable currency rather than an argument.

Choosing Good SLOs

Measure what users feel — pick SLIs tied to user experience (failed/slow requests), not internal vanity metrics like CPU.
Don't aim for 100% — it's unachievable and the cost rises steeply near the top; choose the lowest reliability users won't notice the difference from.
Set realistic targets based on data and user needs — each extra "nine" is roughly 10× the cost/effort.
Window matters — typically 28–30 days rolling; long enough to be meaningful, short enough to act on.

Best Practices

Base SLIs on user-facing behavior (success rate, latency), measured from metrics.
Set SLOs deliberately — the right target is "good enough that users don't notice," not 100%.
Use the error budget as policy — spend it on features when it's healthy, on reliability when it's not.
Alert on burn rate — page when you're consuming the budget too fast, not on every blip (see Alerting).
Review and adjust SLOs as the product and user expectations evolve.

Common Mistakes

Chasing 100% reliability

SLIs that don't reflect user experience

FAQ

What's the difference between an SLI, an SLO, and an SLA?

An SLI is the measurement — a number reflecting service quality from the user's perspective, like the percentage of requests served successfully within 300ms. An SLO is the internal target for that SLI over a window — e.g. 99.9% over 30 days — that your team commits to. An SLA is the external contract with customers promising a (usually looser) level, with financial or contractual consequences if breached. The chain is: SLIs measure, SLOs set the goal you manage to, and SLAs are the customer-facing promise you keep comfortably inside your stricter SLO.

What is an error budget and why is it useful?

An error budget is the allowed amount of unreliability: 100% minus your SLO. A 99.9% monthly SLO gives roughly 43 minutes of permitted failure per month. It's useful because it turns reliability into a spendable currency that resolves the classic tension between shipping features and staying stable: when budget remains, the team can take risks and move fast; when it's exhausted, they pause risky changes and invest in reliability until it recovers. Instead of endless debates between developers and operations, the error budget is the agreed, data-driven policy for that tradeoff.

Why shouldn't I aim for 100% reliability?

Because it's both impossible and the wrong goal. No real system achieves 100% — dependencies, networks, and hardware all fail eventually — and the cost of each additional "nine" of reliability rises roughly tenfold while the user-perceived benefit shrinks toward zero (people genuinely can't distinguish 99.95% from 100%). Chasing perfection diverts huge effort from features users actually want and leaves no error budget to ship with. The right target is the lowest reliability at which users won't notice a difference — enough to keep them happy, not so much that you're spending fortunes on imperceptible gains.

How do SLOs relate to alerting?

SLOs make alerting smarter by tying it to user impact and your error budget rather than raw thresholds. Instead of paging on every CPU spike or transient error, you alert on burn rate — how fast you're consuming the error budget. A fast burn (you'll exhaust the month's budget in hours) warrants an urgent page; a slow burn can be a ticket. This dramatically reduces alert noise and false pages, focusing human attention on problems that actually threaten the reliability target users care about. See Alerting.