Every engineering organization eventually has the same argument. Product wants to ship faster. Operations wants fewer outages. Each side is right, and neither has a shared way to decide when one should win.
Service level objectives — and the error budgets that come with them — are the tool that turns that argument into arithmetic. But first, the vocabulary, because SLI, SLO, and SLA are routinely confused, including by people who use them daily.
The three terms, in plain language
- SLI (service level indicator) is a measurement of how the service is behaving from the user's point of view. Examples: the fraction of requests that succeed, the fraction served faster than 300 ms, the fraction of jobs completed on time.
- SLO (service level objective) is the target you set for an SLI over a time window: "99.9% of requests succeed, measured over 30 days." It's an internal goal that guides engineering decisions.
- SLA (service level agreement) is a contractual commitment to customers, usually with financial remedies if it's missed. SLAs are typically looser than the SLOs behind them, so you have room to react before you owe anyone a credit.
A useful rule: you can have SLIs and SLOs without an SLA, but an SLA without SLOs is a promise you've no way of tracking.
Choosing SLIs that mean something
Good SLIs reflect what users actually experience, not what's easy to measure. CPU usage is a poor SLI because no customer has ever complained about it directly. Better candidates:
- Availability: proportion of valid requests that succeed.
- Latency: proportion of requests faster than a threshold. Prefer percentiles over averages, since averages hide the slow tail that frustrated users actually hit.
- Freshness or correctness: for data pipelines, how recent or accurate the output is.
Start with two or three per service. More than that and nobody pays attention to any of them.
What "nines" actually allow
Here's why asking for "five nines" casually is expensive. This is the downtime each target permits over a 30-day window:
| Availability target | Allowed downtime per 30 days |
|---|---|
| 99% | about 7 hours 12 minutes |
| 99.9% | about 43 minutes |
| 99.95% | about 22 minutes |
| 99.99% | about 4 minutes 19 seconds |
Each extra nine gives you roughly a tenth of the room for error — and typically costs disproportionately more in redundancy, testing, and process. Choose the target your users genuinely need, not the most impressive one.
Error budgets: turning the target into a decision tool
If your SLO is 99.9%, you're explicitly allowing 0.1% failure. That allowance is the error budget.
The idea is liberating. Zero failures isn't the goal; it's unattainable and would freeze all change. The budget is an agreed amount of unreliability you can "spend" on shipping new features, running risky migrations, and the occasional incident.
Error budget = 100% - SLO target
SLO: 99.9% over 30 days -> budget: 0.1%
Total requests this month: 10,000,000
Allowed failed requests: 10,000
Failed so far: 6,500 (65% of budget used)How the budget settles the argument
| Budget state | Typical policy |
|---|---|
| Plenty remaining | Ship freely, take reasonable risks |
| Running low | Slow risky changes, prioritize reliability work |
| Exhausted | Pause feature releases until reliability recovers |
The beauty is that it's agreed in advance. When the budget is spent, it's not operations "blocking" a release out of caution — the pre-agreed policy says reliability work comes first. And when the budget is healthy, engineering has explicit permission to move fast.
Alerting on budget burn
Alerting on every blip is how teams get paged into numbness. A more useful signal is burn rate: how fast you're consuming the budget relative to the window. A fast burn (the whole month's budget gone in a day) pages someone now; a slow burn opens a ticket. This tells you about risk to the objective instead of reacting to each individual error.
Common mistakes
- Setting the SLO to whatever you currently achieve. A target should reflect user needs, not just history.
- Too many SLOs. Focus on the user journeys that matter most.
- No consequences. An SLO nobody acts on is decoration. Write the policy for what happens when the budget runs out.
- Copying someone else's numbers. Another company's 99.99% reflects their users and their costs.
- Treating the SLA as the target. Operate to a stricter internal SLO so you have buffer before breaching a contract.
Where to start
Pick one important service. Choose one availability and one latency SLI. Measure for a few weeks before setting a target, then set an SLO slightly below demonstrated performance and review it quarterly. You'll learn more from the first month of data than from any amount of planning.
Reliability targets are the backbone of site reliability engineering, and our Site Reliability Engineering Fundamentals course walks through SLO design, error budget policies, and incident practice with hands-on exercises. For the measurement side, see Monitoring and Observability Fundamentals. And if your pipeline is part of the reliability story, read CI/CD pipelines that developers actually trust.