Error Budget Calculator

An error budget is the amount of unreliability your SLO allows: budget = 100% − SLO target. A 99.9% SLO over 30 days gives you 0.1% × 30 days ≈ 43 minutes of "allowed" downtime. Instead of treating every minute of downtime as a failure, SRE practice treats the budget as a resource you deliberately spend — on risky deploys, experiments and maintenance — as long as you don't overspend it.

Burn rate measures how fast you're consuming the budget relative to the sustainable pace. Burn rate 1 means you'd use exactly 100% of the budget by the end of the window; burn rate 10 means you're burning ten times too fast and will exhaust it in a tenth of the window. It's the standard way to make error budgets actionable: you alert on burn rate, not on individual failures.

Google's SRE workbook recommends multi-window burn-rate alerts for a 30-day SLO: page immediately when the 1-hour burn rate exceeds 14.4 (you'd burn 2% of the monthly budget in that hour) or the 6-hour rate exceeds 6; open a ticket when the 24-hour rate exceeds 3 or the 3-day rate exceeds 1. Two windows per alert (a long one plus a short 'still burning' check) prevent alerts from firing long after the incident ended.

An SLI (service level indicator) is the measurement itself — e.g. the fraction of successful requests. An SLO (objective) is your internal target for that SLI — e.g. 99.9% over 30 days. An SLA (agreement) is the contractual promise to customers, usually looser than the SLO and with financial penalties attached. The error budget is defined by the SLO; the SLA is what happens when you blow through it badly.

28-day rolling windows are generally better: every window contains exactly four weekends, so week-driven traffic patterns don't skew the math, and the window slides smoothly instead of resetting at midnight on the 1st. Calendar months are easier to explain to customers and match billing periods — which is why SLAs use them even when the internal SLO runs on 28 days.

The classic SRE policy: freeze risky changes — feature releases stop, and engineering effort shifts to reliability work until the budget recovers. The exact policy matters less than having one agreed in advance; the budget only changes behavior if exhausting it has consequences that product and engineering both signed up to.

Because your users can't tell the difference and the cost curve is brutal — each extra nine roughly multiplies the engineering cost. A user on flaky Wi-Fi experiences your 99.99% service and a 100% service identically. The error budget formalises this: reliability above the SLO is not a win, it's an unspent budget you could have used to ship faster.

You need continuous, external measurement of your SLI — for availability that means uptime checks from multiple regions at short intervals, with multi-location confirmation so a single probe's network blip doesn't count against the budget. Each confirmed-down minute is budget spent; an uptime monitoring service tallies this automatically and shows the running total per month.