Error Budget in SRE: Formula, Calculation, and Burn Rate Alerts

An error budget is the amount of unreliability you are allowed to spend in a given period, calculated as 100 percent minus your service level objective. If your SLO is 99.9 percent availability over 30 days, your error budget is 0.1 percent, which is 43 minutes and 12 seconds of downtime. The point of expressing it as a budget rather than a target is that it turns reliability into a resource with a balance: while budget remains, the team can ship quickly and take risks, and when it runs out, reliability work takes priority over features until the balance recovers.

What is an error budget?

The idea comes out of Google's site reliability engineering practice, and it exists to settle a fight that every engineering organization has. Product wants to ship. Operations wants stability. Both positions are reasonable and neither side can win the argument on principle, because the honest answer is that 100 percent reliability is neither achievable nor worth what it costs.

An error budget replaces the argument with arithmetic. You agree on a target, usually as an SLO, and everything below that target becomes an explicit allowance. A 99.9 percent monthly SLO does not mean "try not to go down". It means you have 43 minutes of failure available this month, and how you spend them is a decision rather than an accident. A risky migration that costs you 10 minutes is fine in a month where nothing else broke. The same migration is reckless on the 28th of a month that has already burned 40 minutes.

Three things follow from that framing, and they are the reason the concept stuck:

• Nobody has to be the person who says no. The budget says it. That takes the politics out of a release decision and puts it in a number both teams agreed to in advance.
• Unspent budget is waste, not virtue. A team that finishes every quarter with the budget untouched is being too cautious. They could have shipped more, or they over-invested in reliability nobody asked for.
• It forces you to define what "down" means. You cannot spend a budget you cannot measure, and measuring it means naming the endpoints, the failure conditions, and the measurement window in writing.

How do you calculate an error budget?

The formula is one line:

Error budget = (1 minus SLO) x total time in the period

A 30 day month contains 43,200 minutes. At a 99.9 percent SLO the budget is 0.001 x 43,200 = 43.2 minutes. Here is the same calculation across the targets people actually use.

Availability is the most common indicator, but it is not the only one you can budget. If your SLI is "percentage of requests served successfully in under 500ms", the budget is expressed in failed requests instead of minutes. On 20 million monthly requests at a 99.9 percent SLO, that is 20,000 requests you can afford to serve badly. Request-based budgets suit high traffic APIs better than time-based ones, because a 30 second blip that only touched 40 requests should not consume the same budget as a 30 second full outage during peak.

One detail decides whether the number means anything: the measurement window. A rolling 30 day window is the standard choice, because a calendar month resets the budget at midnight on the 1st and creates an obvious incentive to hold risky work until then. Rolling windows have no cliff, so the budget reflects the last 30 days at all times.

What is error budget burn rate?

The budget alone tells you the balance. Burn rate tells you how fast it is draining, which is the more useful operational signal.

Burn rate = observed error rate / error budget

A burn rate of 1 means you are consuming exactly the amount of budget that would exhaust it precisely at the end of the window. A burn rate of 5 means you are burning five times faster than sustainable, so a 30 day budget would be gone in 6 days. A burn rate of 0 means everything is healthy and the budget is accumulating headroom.

This is what lets you alert on severity rather than on every failed check. Google's SRE Workbook recommends a multi-window, multi-burn-rate setup, and it has become the standard shape:

Read the top row concretely. On a 99.9 percent SLO, a 14.4x burn rate over an hour means about 52 seconds of downtime inside that hour. That is small in absolute terms and easy to shrug off, which is exactly why the burn rate framing matters: sustained at that pace, it eats the entire month in just over two days.

The second window in each row is the thing people skip, and it is what keeps the alert honest. The short window has to be breaching too, otherwise the alert keeps firing long after the incident is over, because the long window still contains the errors. Requiring both means the alert resolves when the problem does.

What is an error budget policy?

A budget with no consequence attached is a dashboard nobody looks at. The policy is the written agreement about what happens when the balance runs out, and it needs to be signed off by the people who own the roadmap, not just by engineering.

A workable policy covers four things. What triggers it, usually the budget being fully consumed within the rolling window. What changes, most commonly a freeze on feature releases with only reliability fixes and security patches allowed through. Who can override it and on what grounds, because there will be a legitimate emergency exception and it is better to define it in advance than to improvise. And how the freeze ends, which is normally when the rolling window recovers enough budget rather than after a fixed number of days.

The freeze is the part that generates resistance, so it helps to be clear about what it is for. It is not a punishment. It redirects the same engineering hours from new features into the work that stops the budget being spent next month: the flaky dependency, the missing retry, the deploy that takes the site down for 40 seconds every time. Most budget-burning incidents arrive attached to a change, which is why the highest-leverage reliability investment for a lot of teams is not more monitoring at all, it is making releases boring: zero downtime deployments with a rollback you can trigger in one step remove an entire category of self-inflicted outage.

One more rule worth writing down: exclusions. Planned maintenance announced in advance is normally excluded from the budget. Failures caused by a customer's own misconfiguration usually are too. Everything else counts, including third party outages, because your users do not care whose fault it was.

Common mistakes when setting an error budget

Setting the SLO to match the SLA. These should not be the same number. The SLA is the contractual promise with financial consequences. The SLO is your internal target, and it belongs tighter than the SLA so that burning your internal budget is a warning rather than a breach. If you sell 99.9 percent, run the SLO at 99.95 percent. Our page on SLA monitoring and uptime compliance covers where that line sits.

Picking a target because it sounds impressive. Four nines is a real architectural commitment: cross-region redundancy, automated failover, and a monthly downtime allowance of four minutes that a single bad deploy will exceed. Set the target at what the business genuinely needs, and read what counts as a good uptime percentage before committing to a number you cannot staff.

Measuring only from inside your own infrastructure. A health check that runs on the same host as the application will report success while DNS is broken, a certificate has expired, or a load balancer is refusing connections. The budget should be measured the way a customer experiences the service, which means external checks from more than one location.

Budgeting the homepage instead of the product. A marketing page returning 200 is not evidence that login, checkout, or the API is working. Scope the SLO to the user journeys that actually matter and measure each one separately.

Never reviewing the number. An SLO set 18 months ago against a smaller system with different dependencies is probably wrong now. Revisit it quarterly, along with whether the budget is being systematically underspent, which is its own signal.

How to measure an error budget in practice

You need three ingredients, and only the third one is a tooling question.

First, a defined SLI: the specific measurement, such as the percentage of HTTP checks that returned a 2xx within your latency threshold. Second, the SLO and the window: the target and the period it is measured over. Third, a continuous, external, timestamped record of every failure, retained long enough to cover the window.

That third piece is where most implementations quietly fall apart. Reconstructing downtime from chat history and memory at the end of the month produces a number nobody trusts, and it always rounds in the direction of whoever is doing the reconstructing. What you want instead is checks running on their own schedule from outside your network, recording start and end timestamps for every incident automatically. Synthetic checks against your critical endpoints do exactly that, and running them from multiple regions with cross-region confirmation stops a single flaky network path from charging your budget for downtime your users never experienced.

Interval matters more than people expect once the targets get tight. A five minute check interval cannot detect a 99.99 percent breach at all, because the entire monthly budget of four minutes is shorter than one gap between checks. If you are budgeting at four nines, you need checks running every minute at minimum. Our guide on how often you should check a website works through the tradeoff.

Finally, publish it. An error budget reviewed by three engineers in a private dashboard has far less effect than one visible to the whole team, and uptime history published on a public status page makes the commitment real to customers too.

The short version

An error budget is 100 percent minus your SLO, expressed as time or failed requests. At 99.9 percent over 30 days that is 43 minutes and 12 seconds. Track burn rate rather than raw balance, alert with paired long and short windows so alerts resolve when the incident does, and write a policy that says what happens when the budget is gone. Set the SLO tighter than any SLA you sell, scope it to the journeys that matter, and measure it externally from more than one region so the number survives an argument. The goal is not to protect the budget. It is to spend it deliberately.