Error budget: the formula, burn rate alerts, and the policy that makes it work

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.

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.

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.

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.

Time-based or request-based? The distinction that trips people up

There are two ways to count, and they answer different questions. A time-based budget counts minutes the service was down, which is what an external uptime monitor measures and what almost every customer contract is written against. A request-based budget counts bad events divided by total events, which is what Google's SRE material assumes and what matches user experience more closely.

They diverge badly under partial failure. If 5% of requests fail for two hours, a time-based monitor probably records zero downtime, because its own checks mostly succeeded. A request-based budget records a real and significant spend. Neither is wrong; they measure different things. Most teams end up running a time-based budget for the contractual number and a request-based one for the engineering conversation. If the thing you are budgeting is a data pipeline rather than an API, neither works well and you want freshness, volume and schema signals instead, because a pipeline that returns stale data on time is failing without ever being down.

What is error budget burn rate?

Burn rate is how fast you are consuming the budget relative to the rate that would exhaust it exactly on schedule. A burn rate of 1 means you finish the period with the budget spent to zero. A burn rate of 2 means you run out halfway. It is a normalized speed, which is what makes it useful for alerting: the same threshold works for a 99.9% and a 99.99% service without rewriting it.

Those exhaustion times assume a 30-day SLO window, which is the basis Google's workbook uses, so they run marginally short against the 30.44-day average month used earlier on this page. The rank order is what matters, not the last minute of precision.

Burn rate alert thresholds that do not page you at 3am for nothing

The problem with alerting on a single burn rate over a single window is that you pick between fast and noisy or calm and late. Google's published answer is the multiwindow, multi-burn-rate alert: require both a long window and a short window to breach the threshold at the same time. The long window gives significance, the short window makes the alert stop firing once the problem is over. This is their recommended starting configuration for a 99.9% SLO.

Read the last column, because it is the design goal. The top rule wakes a human when 2% of the month's budget is gone in an hour. The bottom rule quietly files a ticket when a slow leak has taken 10% over three days, which is the class of problem that never pages anyone and eventually eats the whole allowance. Two pages and one ticket is a deliberately small number of rules.

Four mistakes that make an error budget useless

Setting the target from ambition rather than data. If you have been running at 99.5% and you write 99.99% into a policy, you have created a budget that is exhausted permanently and a freeze everyone learns to ignore. Start from what you actually delivered last quarter. Our guide to what counts as a good uptime percentage covers where the realistic numbers sit by service type.

Measuring with a sampling rate that cannot see the budget. At 99.99% your entire monthly allowance is 4 minutes 23 seconds. A monitor checking every 5 minutes can miss the whole thing, and even a 60-second check spends roughly a ninth of that budget just noticing. The interval you measure at sets the smallest outage you can prove, which is why check frequency is a budgeting decision. That constraint is what separates monitoring tools at this tier, and it is the core of our HetrixTools alternative comparison, since HetrixTools holds a one-minute floor on every plan.

Never spending it. A team that finishes every month at 5% consumption is not winning, it is over-provisioned. Unspent budget is permission to ship faster, run a chaos test, or do the migration you have been deferring. Consistently untouched budget means the target is set too low to be informative.

Confusing the budget with MTTR. They pull in the same direction but measure different things: the budget caps total downtime, while MTTR measures how quickly you recover from each incident. You can hold a good MTTR and still blow the budget through frequency alone.

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.

For the contractual side, the budget feeds directly into what you report to customers. If your agreement carries credits, the budget is the early warning that credits are coming, and the monthly evidence is what an uptime SLA report is for. If you are choosing tooling specifically to evidence a target, SLA monitoring software compares what the options can actually document.

Questions people ask about error budgets

What does a burn rate of 1 mean?

A burn rate of 1 means you are consuming the error budget at exactly the pace that spends all of it by the end of the SLO period, and no faster. It is the break-even rate. A burn rate of 2 spends the budget in half the period, and a rate of 10 spends it in a tenth. The measure is normalized, so the same threshold applies across services with different targets.

How do you calculate error budget burn rate?

Divide the share of budget consumed in a window by the share of the period that window represents. If 2% of a monthly budget is gone in one hour, that hour is one 720th of a 30-day month, so the burn rate is 0.02 divided by 0.00139, which is roughly 14.4. In practice you configure this as a query over your error rate rather than computing it by hand.

Should error budgets reset monthly or roll?

A rolling window, usually 28 or 30 days, is the better default. Calendar resets create a cliff where an incident on the 31st is forgiven the next morning, which encourages exactly the wrong behavior at month end. Calendar months are easier to explain to non-engineers and match billing periods, so if your budget is customer-facing, that convenience may be worth the cliff.