SLI, SLO, and the error budget: reliability by the numbers

A product manager asks: “Can we ship the new checkout flow this week?” Without an SLO, the answer is a feeling. With one, it is arithmetic — the error budget either has headroom or it does not.

What the three terms actually mean

SLI (Service Level Indicator) is a ratio: the fraction of requests (or events) that were “good” out of everything that was attempted. For a request-driven service, “good” typically means: returned a successful status code, within an acceptable latency. The formula is always the same shape — good events / total events — and the result is a number between 0% and 100%.

SLO (Service Level Objective) is the target you commit to for that SLI. If you pick 99.9%, you are saying: at least 99.9% of requests must be good. Everything above the target is surplus. Everything below is a failure.

Error budget is what remains under the target: 1 − SLO. A 99.9% SLO leaves a 0.1% budget of failures you are allowed to produce before the SLO is breached.

The data-plan metaphor

Think of the error budget like a monthly mobile data plan. A 99.9% SLO over 30 days has the same shape as “10 GB per month”: you start the period with a fixed allowance, you spend it as events happen, and if you run out before the period ends, you slow down — no new feature deploys — until the next billing cycle resets.

A small incident is like a 30-second video: barely a dent. A two-hour outage is like streaming HD all weekend: most of the month’s quota gone. Teams that are heavy spenders ration carefully; light spenders ship freely. The budget is a real resource, not a metaphor in the system — when it goes negative, real consequences follow.

Burn rate: the derived quantity that matters most

Burn rate normalises the error rate against the SLO target:

burn_rate = actual_error_rate / (1 − SLO)

At the 99.9% SLO (budget = 0.1% = 0.001):

• 0.1% error rate → burn rate 1.0: you would exhaust the budget exactly by month-end
• 1.44% error rate → burn rate 14.4: you would exhaust the 30-day budget in about 2 days

A burn rate of 1 means “sustainable.” Above 1 means you are on pace to miss the SLO. The burn rate is what alerts and dashboards show, because it is the same number regardless of the SLO target or traffic volume — 14.4x means the same thing on any service.

A concrete scenario

A SaaS team sets a 99.5% SLO. Over a month they serve 10 million requests; 0.5% = 50,000 errors allowed. A config bug in week one burns 30,000 errors in 20 minutes — 60% of the monthly budget in one incident. The burn-rate alert fires; the postmortem uses the burned budget as the severity metric. The remaining 40% covers the next 20 days only at the baseline error rate — no room for a risky deploy. The team ships the planned feature behind a feature flag instead.