“Should we ship this risky feature or spend the sprint hardening the system?” is an argument that goes nowhere when it’s opinion versus opinion. An error budget turns it into a number: do you have room to burn, or not.

What an error budget is

If your SLO is 99.9% uptime over 30 days, your error budget is the other 0.1% — the amount of failure you’re allowed before you breach the target. Over 30 days, 0.1% is about 43 minutes of downtime.

Error budget = (1 - SLO) × time window
99.9% SLO over 30 days = 0.1% × 43,200 minutes ≈ 43 minutes

That budget is a resource, same as compute or headcount. You spend it on deploys that go wrong, on risky features, on planned maintenance. When it’s gone, it’s gone until the window rolls forward.

Tracking burn rate

Burn rate is how fast you’re spending the budget relative to how fast you’re allowed to. A burn rate of 1 means you’re on pace to use exactly 100% of the budget by the end of the window — sustainable. A burn rate of 10 means you’ll exhaust a 30-day budget in 3 days if it keeps up.

# fast burn: would exhaust 30-day budget in ~1 hour if sustained
(
  sum(rate(http_requests_total{status=~"5.."}[5m]))
  /
  sum(rate(http_requests_total[5m]))
) > (14.4 * 0.001)

14.4 here comes from Google’s SRE workbook multi-window burn rate approach — it’s the threshold where a 5-minute error rate, if sustained, would blow a 30-day 99.9% budget in about 2 hours. You don’t need to derive it yourself; the point is: a short-window burn-rate alert catches fast, severe failures long before a 30-day rolling average would notice.

The decision the budget settles

flowchart TD
    A[Feature or deploy proposed] --> B{Error budget remaining?}
    B -->|Plenty left| C[Ship it, accept the risk]
    B -->|Mostly spent| D[Ship only low-risk changes]
    B -->|Exhausted| E[Freeze features, fix reliability]
    E --> F[Budget resets next window]
    F --> B
  

This is the actual value of the exercise. Without it, “should we ship” is a debate about risk tolerance that restarts from zero every time. With it, the rule is fixed in advance: budget available means normal velocity, budget exhausted means you stop shipping features and fix what’s breaking, no negotiation needed in the moment.

Setting the freeze threshold before you need it

Agree on what “exhausted” triggers before an incident, not during one:

Write this down somewhere the whole team can point to. The value isn’t the exact thresholds — it’s that they’re decided when nobody’s mad about a recent outage, so the freeze isn’t a punishment, it’s just what the rule says happens next.

The trap: budgets that never reset

If your window is a rolling 30 days, a bad week three weeks ago is still costing you budget today. That’s intentional — it stops a team from having one terrible week, blowing the SLA, and then coasting on a clean slate the next morning. Sustained reliability, not a short memory, is what the rolling window enforces.

Once you’ve got a burn-rate alert wired to something that pages you, the earlier three-alert Prometheus setup is worth revisiting — a burn-rate rule belongs right alongside disk space and instance-down as one of the alerts actually worth having.