An error budget is the amount of downtime or errors your reliability target allows over a period. If your goal is 99.9% uptime, you are accepting 0.1% of unreliability, which works out to about 43 minutes of downtime a month. That 43 minutes is your error budget. As long as you have budget left, you can ship fast; when you burn through it, the team's job shifts to fixing reliability instead of adding features.
The idea comes from Google's site reliability engineering practice, and it exists to settle an argument that every team has: developers want to ship, operations wants stability, and the two pull against each other. An error budget replaces the argument with a number. Nobody has to win the debate over how reliable is reliable enough, because the target is agreed up front and the budget just tracks how much of it you have spent.
What is an error budget?
An error budget is the inverse of your reliability target. Set a service level objective, or SLO, of 99.9% uptime and you are explicitly saying that 0.1% downtime is acceptable. The error budget is that 0.1%, expressed as real time or a count of failed requests. It reframes reliability from a vague ideal into a quantity you can measure, spend and run out of.
The key insight is that 100% is the wrong target. A service that never fails is impossibly expensive to build and, past a point, users cannot tell the difference. The error budget makes that trade-off explicit: a small, deliberate allowance for failure that you get to spend on shipping, maintenance and the normal risk of running software.
How do you calculate an error budget?
Take your SLO, subtract it from 100%, and apply the remainder to the time window. The math is straightforward once you see the fractions of a month laid out.
| Uptime SLO | Error budget | Downtime allowed per month |
|---|---|---|
| 99% | 1% | About 7 hours 18 minutes |
| 99.9% (three nines) | 0.1% | About 43 minutes |
| 99.95% | 0.05% | About 21 minutes |
| 99.99% (four nines) | 0.01% | About 4 minutes 20 seconds |
| 99.999% (five nines) | 0.001% | About 26 seconds |
You can measure the budget in time, as above, or in requests: with a 99.9% success SLO on a service handling a million requests a month, your budget is a thousand failed requests. Request-based budgets fit APIs better, because a short blip during low traffic costs fewer requests than the same blip at peak. For a fuller walkthrough of the percentages, see what counts as a good uptime percentage.
What is an error budget policy?
An error budget policy is the rule that decides what happens when the budget runs low or runs out. It is the part that gives the number teeth. A typical policy has thresholds: while budget is healthy, ship freely; when it drops below a set level, slow down risky changes; when it is exhausted, freeze feature work and spend the sprint on reliability until the budget recovers.
Without a policy, an error budget is just a dashboard nobody acts on. The policy is what turns a burned budget into a real decision: a feature freeze, a rollback, a postponed launch. Agreeing it in advance, when nobody is mid-incident, is what stops it from becoming a fight later.
alertping
You cannot budget what you do not measure
An error budget is only as honest as your uptime data. AlertPing checks every 30 seconds from three regions and records every second of downtime, so your budget reflects reality. SMS on every plan, flat from $19 a month.
Why do teams use error budgets?
Because they end the reliability-versus-velocity standoff with data instead of opinion. When the budget is healthy, the team has proof it can afford to move fast: an error budget with room to spare is permission to ship and deploy changes aggressively, because you have measured headroom for the occasional bad release. When the budget is spent, the same data makes the case for slowing down, without anyone having to play the villain.
It also aligns incentives. Developers and operations share one number, so shipping a risky change and keeping the service up stop being separate goals owned by separate teams. Everyone is spending, or saving, the same budget.
Error budget vs SLA vs SLO
These three get tangled constantly. The SLO is your internal target, the error budget is what that target leaves you to spend, and the SLA is the external promise with money attached.
| Term | What it is | Who it is for |
|---|---|---|
| SLO (objective) | The reliability target you aim for | Internal, the engineering team |
| Error budget | The downtime the SLO allows you to spend | Internal, shared across teams |
| SLA (agreement) | The promise to customers, with credits if missed | External, customers and sales |
A healthy setup keeps the SLO tighter than the SLA, so you notice you are in trouble and act while there is still budget, well before you breach the customer promise. For the full breakdown, see SLA vs SLO vs SLI and the SLA monitoring guide.
How do you track an error budget?
You track it by measuring real availability against your SLO, continuously. That means monitoring that records every outage accurately, down to the second, because a budget built on rounded or missed downtime is worse than none: it tells you that you are fine when you are not. Short check intervals matter here, since a monitor that only looks every five minutes can miss a two-minute outage entirely and quietly overstate your remaining budget.
In practice, teams pull downtime from their monitoring tool, compare it against the budget for the period, and watch the burn rate: how fast the budget is being consumed. A sudden spike in burn rate is an early warning that something is degrading, often before it turns into a full outage. That is the real value of the budget: not a report you read after the fact, but a live signal you steer by.
Start simple. Pick one SLO for your most important service, work out the monthly budget from the table above, and measure against it for a quarter. The first time you watch a bad week eat half your budget, the abstraction becomes concrete, and the conversations about what to ship and what to fix get a lot easier.