What is an error budget?
An error budget is the amount of failure a service may have before it misses its SLO, calculated as (1 − SLO) × the measurement period or × the number of requests. A 99.9% SLO over 30 days gives 43.2 minutes of downtime. While budget remains, teams ship; when it runs out, reliability work comes first.
Why an error budget matters
An SLO on its own is a pass or fail line. The error budget turns it into a quantity you can spend and track: how much room is left this month, and how fast it is being used.
It gives product and operations a shared rule instead of an argument. If the budget is healthy, riskier releases are fine; if a bad week burned most of it, the team slows down and fixes what caused it. Google's SRE books made this practice widely known, and the idea behind it is simple: 100% reliability is the wrong target, because users cannot tell 99.99% from 100% and every extra nine costs more than the last.
How to measure an error budget
error budget = (1 − SLO) × period
= (1 − SLO) × valid requests (request-based SLOs)
budget used = bad minutes (or bad requests) so far ÷ error budget
burn rate = observed error rate ÷ (1 − SLO)
time to exhaust = period ÷ burn rate
Worked example
A service has a 99.9% availability SLO over 30 days. Today its error rate is 0.6% and stays there.
- Budget in time = (1 − 0.999) × 30 days × 1,440 minutes = 43.2 minutes.
- Burn rate = 0.6% ÷ 0.1% = 6.
- At a burn rate of 6, the whole 30-day budget is gone in 30 ÷ 6 = 5 days.
- For comparison, the SRE workbook's fast-burn page fires at a burn rate of 14.4 over one hour, which uses 14.4 × 1 ÷ 720 = 2% of a 30-day budget in that hour.
Result: A burn rate of 6 deserves a page, not a ticket: left alone, the month's SLO is lost before the week is out.
SLI, SLO, SLA and error budget: how they fit together
- SLI (service level indicator): the measurement, always good events ÷ valid events, such as the share of successful requests.
- SLO (service level objective): the internal target for that SLI over a window, such as 99.9% over a rolling 30 days.
- SLA (service level agreement): the promise to customers, with service credits attached. Keep it looser than the SLO (99.9% SLA behind a 99.95% SLO) so you are warned before money is owed.
- Error budget: 100% minus the SLO, in minutes or requests: the part of the SLO you may miss.
Allowed downtime for common SLO targets
Each figure is (1 − SLO) × the window. A 30-day window has 43,200 minutes and a 90-day quarter 129,600, so the quarterly budget is exactly three times the monthly one.
| SLO | Error budget | Allowed downtime per 30 days | Per quarter (90 days) | Failed requests allowed per million |
|---|---|---|---|---|
| 99% | 1.00% | 432 min (7 h 12 min) | 1,296 min (21 h 36 min) | 10,000 |
| 99.5% | 0.50% | 216 min (3 h 36 min) | 648 min (10 h 48 min) | 5,000 |
| 99.9% | 0.10% | 43.2 min (43 min 12 s) | 129.6 min (2 h 9 min 36 s) | 1,000 |
| 99.95% | 0.05% | 21.6 min (21 min 36 s) | 64.8 min (1 h 4 min 48 s) | 500 |
| 99.99% | 0.01% | 4.32 min (4 min 19.2 s) | 12.96 min (12 min 57.6 s) | 100 |
Other targets and periods: the SLA and uptime calculator. Each extra nine divides the budget by ten.
Request-based vs time-based error budgets
Time-based budgets count bad minutes: minutes when the service was down, or when its error rate crossed a line you chose. They suit uptime checks, but a quiet minute at 3 a.m. costs as much as one at peak. Request-based budgets count failed requests out of valid ones, so a failure costs in proportion to the traffic it hurt; they suit APIs. Decide what is excluded, such as 401s for bad credentials, and write it down.
Worked example: a request-based budget
An API with a 99.9% SLO serves 25,000,000 requests in 30 days, so its budget is 25,000 failed requests. By day 12 it has had 9,500 failures: 38% of the budget used, 15,500 failures left. Day 12 is 40% of the period, so it is spending slightly slower than an even pace.
Burn rate and multi-window, multi-burn-rate alerts
Burn rate compares how fast the budget is being spent with the pace that would use exactly all of it by the end of the window. At 1 it lasts 30 days; at 14.4 a 30-day budget is gone in 50 hours. Google's SRE workbook pairs a long window, proving the problem is big enough to matter, with a short one, proving it is still happening, so the alert also clears soon after the fix. Both must exceed the burn rate. For a 99.9% SLO over 30 days (720 hours):
| Alert | Burn rate | Long window | Short window | Error rate that trips it | Budget used when it fires | Whole budget gone in | Action |
|---|---|---|---|---|---|---|---|
| Page | 14.4× | 1 hour | 5 minutes | 1.44% | 2% of the budget | 50 hours | Page the on-call engineer now |
| Page | 6× | 6 hours | 30 minutes | 0.6% | 5% of the budget | 120 hours (5 days) | Page the on-call engineer now |
| Ticket | 1× | 3 days | 6 hours | 0.1% | 10% of the budget | 720 hours (30 days) | Open a ticket for working hours |
Budget used = burn rate × long window ÷ 720 hours: 14.4 × 1 ÷ 720 = 2%, 6 × 6 ÷ 720 = 5%, 1 × 72 ÷ 720 = 10%. The error rate that trips each alert is burn rate × 0.1%; at a 99.5% SLO the fast page fires at 7.2% errors.
An error budget policy template
A budget only changes behaviour if everyone agreed beforehand what happens as it runs down. Write the policy before the first bad month and have product and engineering sign it. A starting point:
| Budget consumed (rolling 30 days) | What happens |
|---|---|
| 50% | Review the top causes at the next weekly meeting and ticket each one. Releases continue. |
| 75% | Risky changes (schema migrations, infrastructure moves) need the service owner's approval. One reliability fix enters the current sprint; new features ship behind flags. |
| 100% | Feature releases freeze until the rolling window is back under budget; security and reliability fixes still ship. Any single incident that used more than 20% of the budget gets a postmortem. |
Write down the exceptions too, such as outages caused by a provider you do not control. Google's published example policy uses the same 20% postmortem rule.
Do maintenance windows count against the error budget?
Decide before the window, and base it on what users see. If they cannot use the service, counting the window is the honest choice; many teams do, and schedule maintenance when the budget can afford it. Excluding it is reasonable when the window is announced in advance on a status page, short, and excluded in the SLA text. Rolling deploys should not need a window at all, and errors they cause always count.
Common mistakes
- Treating the budget as a target. The budget is permission, not a goal. Nobody needs to break things to use it up.
- Counting maintenance inconsistently. Decide in advance whether planned maintenance counts against the budget, and write it into the SLO.
- Alerting on every error. Alert on burn rate instead: a fast burn pages someone, a slow burn opens a ticket.
- No policy for an empty budget. If nothing changes when the budget is gone, it is only a chart. Agree what happens (freeze risky releases, prioritise fixes) before you need it.
- An SLO tighter than you can measure. A 99.99% SLO checked once a minute cannot see most of a 4-minute budget being used. The check interval must be much shorter than the budget.
- Measuring from inside the data centre only. A health check next to the server misses DNS, TLS and network failures users hit. Measure the SLI where users are, or as close as you can get.
How Vigil handles an error budget
- Set an SLO target (for example 99.9) on any monitor and Vigil tracks a time-based error budget over a rolling 30 days: (1 − SLO) × 30 days, spent by the monitor's down incidents. The monitor page shows achieved uptime, budget, used and remaining; the SLO dashboard tile shows them as bars.
- The printable SLA report covers 30 or 90 days: achieved availability against target, error budget, downtime and each incident, ready to save as PDF for a customer.
- A failure that starts inside a maintenance window opens no incident and sends no alert, so it is not charged to the budget; failed checks still count in the achieved-uptime percentage.
- Failures are confirmed by a second check before they open an incident. Vigil does not compute burn-rate alerts itself; the free SLA and uptime calculator and the 99.9% uptime page give allowed downtime for any target.
Error budget: frequently asked questions
What happens when the error budget runs out?
Whatever your error budget policy says. A common policy pauses risky feature releases and spends the time on fixes until the budget recovers in the rolling window.
Is the error budget measured in time or in requests?
Either. Time-based budgets suit uptime checks (minutes of downtime). Request-based budgets suit APIs: with 10 million requests a month and a 99.9% SLO, 10,000 requests may fail.
What is a burn rate?
How fast the budget is being used relative to the pace that would use exactly all of it by the end of the period. A burn rate of 1 uses it all in the period; 2 uses it in half the time.