Module 02 · Lesson 03
Reliability: SLIs, SLOs and error budgets
Write down what 'working' means, measure it, then decide how much failure you can afford.
What you will be able to do
- Define an SLI that can actually be measured
- Convert an SLO into an error budget and a burn rate
- Distinguish an SLO from an SLA and say who each protects
- Decide what to freeze when the budget is spent
The three letters, in order
| Term | Is | Example |
|---|---|---|
| SLI | A measured indicator of service health | Share of requests answered in under 300 ms |
| SLO | The internal target for that indicator | 99.9% of requests under 300 ms, per 30 days |
| SLA | A contract with a customer and a penalty | 99.9% monthly uptime, 10% service credit below it |
Order matters. An SLI you cannot measure is a wish, an SLO without an SLI is a slogan, and an SLA without headroom above the internal SLO is a lawsuit waiting for its first bad week. Internal targets should sit above external promises, so you notice trouble before a customer does.
Turning a target into a budget
SLO: 99.9% of requests succeed, measured monthly Traffic: 10M requests per month allowed failures = 0.1% x 10M = 10,000 requests burn rate = failures / budget 2,000 failures in the first week = 20% of the month's budget if that pace held, the budget is gone in ~5 weeks of traffic... i.e. at that rate you exhaust a month's budget in 5 days of traffic.
The point of the arithmetic is the decision it forces. A fast burn early in the month means stopping feature work to fix reliability — that is what the budget is for. Without it, the discussion becomes a negotiation about feelings after every incident.
Measure what the user feels
Prefer SLIs at the edge — success rate and latency of the user-facing request — over CPU graphs inside the fleet. A service can be at 30% CPU and still fail every request because a dependency is down. Health is what the user got, not what your servers are doing.
Choosing an indicator worth having
- Prefer ratios to totals: "share of requests under 300 ms" survives traffic growth; "average 240 ms" does not.
- Attach a window: 30 days is standard, 7 days for fast-moving systems, because long windows hide fresh damage.
- Keep a small set. Three or four SLIs — availability, latency, error rate, maybe freshness — are enough to run a service.
- Exclude what you cannot control only if you can say so out loud; otherwise you are hiding failures.
Q. Our SLO is 99.9% and we are at 99.95%. Should we relax it?
Only after asking what it costs to hold. Regularly exceeding a target usually means the target is too loose for the money being spent. Tighten it or bank the savings by simplifying the system — but decide deliberately, and check the tail before relaxing anything.
Q. Where does availability budget fit into a design interview?
Use it to justify redundancy. "99.95% allows about 22 minutes a month; a single primary with a 10 minute failover eats half of that, so I would want automated promotion." The number makes the redundancy argument instead of an opinion.
Worth remembering
- SLI is the measurement, SLO is the target, SLA is the contract with a penalty attached.
- A 99.9% monthly SLO over 10M requests allows 10,000 failed requests that month — that is the budget.
- Error budgets turn 'should we ship?' into arithmetic: spend the budget on features, freeze when it is gone.
- Reliability is a feature with a cost curve, not a moral position. Ask what the target is worth.
Checkpoint
Answer all 2 questions to finish the lesson.
1. What is the difference between an SLO and an SLA?
SLOs are internal goals that guide engineering. SLAs are external promises with consequences, so internal targets should leave headroom above them.
2. An SLO of 99.9% over one million monthly requests allows how many failures?
0.1% of 1,000,000 is 1,000 requests. That number is the error budget the month is allowed to spend.