Stop 11 · Monitoring & ObservabilityTopics · 8/9

SLIs, SLOs & Error Budgets

In short

'Make it 100% reliable' sounds good, but it means never shipping anything. SLOs give teams an agreed reliability target and an error budget, a clear amount of failure you're allowed to 'spend' on moving fast.

An SLI is a measured indicator (e.g. request latency), an SLO is the target for that indicator (e.g. 99.9% of requests under 200ms), and the error budget is the acceptable amount of failure before the SLO is at risk.

The mascot with a college bag counts the crossed-out days left on a wall calendar.

Think of it like this

The 75% attendance rule

Many colleges require 75% attendance. That quietly gives you a budget: you can miss a quarter of classes for fests or illness. Bunk too much early in the term and you must attend everything later. An SLO works the same way; the error budget is your allowed bunks.

Watch it happen

A 30-day error budget at 99.9%

SLO 99.9%

Budget 43 min

Used 0 min

Left 43 min

1/4The SLO: 99.9% of minutes in 30 days must be good. 0.1% of 43,200 minutes is about 43 minutes of budget.

The big ideas

What you need to know

SLI: what you measure

A ratio of good events to total events, like requests under 300 ms divided by all requests.

SLO: the target

The SLI goal over a window, like 99.9% over 30 days. Set it from what users need, not from what's easy.

Error budget: allowed failure

100% minus the SLO. While budget remains, ship freely. When it's spent, slow down and fix reliability.

SLA is a contract

An SLA is a promise to customers, often with refunds. Keep your internal SLO stricter than any SLA.

See it in code

Walk through the code

text

1SLI  = good requests / all requests2SLO  = SLI >= 99.9% over 30 days3 4Error budget = 100% - 99.9% = 0.1%5  1,000,000 requests/month  ->  1,000 can fail6  30 days of uptime         ->  43.2 minutes of downtime

1/2Define good, measure it as a ratio, and set a target over a rolling window.

Every extra nine shrinks the budget tenfold. 99.99% over 30 days leaves only about 4.3 minutes.

Save yourself the pain

Common mistakes

Oops

Setting a 99.999% SLO because higher sounds better.

Do this instead

Pick what users actually notice. Each extra nine costs far more effort and slows every release.

Oops

Measuring server uptime instead of the user's experience.

Do this instead

A server can be up while every request fails. Base SLIs on real requests, ideally close to the user.

Your mission

Write an SLO for something real

~25 min

Quick check

Your 30-day SLO is 99.9%, and you've used the whole error budget by day 18. What should usually happen?

Go deeper

1Define an SLI and SLO for a hypothetical service (e.g. API uptime).
2Calculate the error budget implied by a 99.9% availability SLO over a month.
3Learn why error budgets give teams a data-driven way to balance reliability work against new feature work.