SLIs, SLOs, and the Error Budget

"We need five nines." Someone says it in a planning meeting and everyone nods, and nobody points out that five nines is 26 seconds of downtime per month, which is less time than a deploy takes.

Availability targets are not aspirations, they are budgets. Choosing one means choosing what you will spend to defend it and what you will give up to afford it. Getting that trade explicit is the entire value of the SLO framework, laid out in the Google SRE book and its workbook.

Three terms, one relationship

1. SLImeasurethe indicator: a measured ratio of good events to valid events
2. ↓
   SLOtargetyour internal target for that indicator, over a window
3. ↓
   SLAmoneya contract with a customer, and a refund when you miss

The SLI is a number your telemetry produces. The SLO is the line you drew on it. The SLA is a promise with financial consequences, and it should always be looser than your SLO, because you want to find out you are in trouble before your customers get paid for it.

Most teams only need the first two. If you have no contractual penalty, you have no SLA, and calling your target an SLA just makes it harder to change.

Pick an indicator users can feel

The standard shape is a ratio of good events to valid events:

availability = successful requests / valid requests
latency      = requests faster than 300ms / valid requests

Two words in there carry the weight.

Good means good to the user. A 200 that returns an empty list because a downstream call timed out is a successful request and a failed experience; a 429 to a client hammering you is arguably a success.

Valid is what you agree to count: not health checks, not a bot ignoring your rate limits, not 400s from a malformed payload. That definition is where the honest argument lives, and writing it down is what stops it being renegotiated mid-incident.

For a request-driven service, three SLIs usually cover it: availability (success ratio), latency (ratio of requests under a threshold), and, if the service does asynchronous work, freshness (ratio of data updated within some age). Three is a ceiling, not a floor. An SLO nobody looks at is worse than no SLO.

What the nines cost

Convert the target to time immediately, because percentages hide how brutal the upper end is.

At 43 minutes a month, someone can be paged, wake up, read a dashboard, and roll back. At 4.3 minutes that sequence does not fit, so every recovery path has to be automatic, which is a different and far more expensive system.

There is also a ceiling: you cannot be more available than the dependencies you require. Three required dependencies at 99.9% each put you at about 99.7% before you write any code.

The budget is meant to be spent

The inverse of the SLO is the interesting half. A 99.9% target grants 0.1% of failures, and that allowance is a resource with a rule attached: while budget remains, ship; when it is gone, stop shipping and stabilize.

This turns a culture argument into arithmetic. "Are we shipping too fast?" has no answer; "we burned 80% of the quarter's budget in three weeks" has an obvious one. It works in reverse too: an unspent budget means the target is too loose, or you are being too cautious. Six perfect months is not a triumph, it is evidence you could have shipped more.

Alerting on burn rate rather than on instantaneous errors is the practical payoff. A 5% error rate for thirty seconds may be irrelevant; a 0.5% error rate sustained for six hours eats the month. Burn-rate alerts fire on the second one and stay quiet for the first, which is most of the way to a pager that people trust.

Setting the first number

Do not derive it from ambition. Measure what the service did last month and set the target just below that, then tighten it once. Achievable, honest about regressions, and no political fight about a number nobody can hit.

Two questions keep it that way. What does the user do when this breaks, because if they retry in twenty seconds and lose nothing, the target can be looser than you think. And what is the cheapest way to be more reliable, because it is usually not more nines here but a retry policy, a queue, or a cached fallback in the caller, which is what the resilience patterns are for.

The target also has a capacity consequence. Serving p99 under 300ms during your peak, with a failed instance, is a statement about how much headroom you keep, and headroom is the next lesson.

Key takeaways

• SLI is the measurement, SLO is your internal target, SLA is a contract with money attached. Keep the SLA looser than the SLO.
• Define "good" as good to the user and "valid" as what you agree to count. Write both down before an incident, not during one.
• Convert nines to minutes immediately. The wall is between 99.9% (43 min/month, a human can respond) and 99.99% (4.3 min/month, nothing manual fits).
• You cannot be more available than the dependencies you require, so count them before promising anything.
• The error budget is a spending decision: burning fast means freeze and stabilize, barely spending means the target is too loose.
• Alert on burn rate, not instantaneous error rate, and set your first target just below what the service already achieves.