Skip to main content
An error budget is the amount of unreliability a service is allowed before it violates its service level objective (SLO). It equals 100% minus the SLO target: a service with a 99.9% availability SLO has a 0.1% error budget. The budget can be “spent” on incidents, risky deploys, and planned maintenance — and when it runs out, the team shifts focus from shipping features to restoring reliability.

​
How do you calculate an error budget?

Applied to a time window, the percentage converts into concrete minutes of allowed downtime (or a count of allowed bad requests, for request-based SLOs).

​
Worked example

A service has a 99.9% availability SLO measured over a 30-day window.
  • Error budget = 100% − 99.9% = 0.1%
  • Minutes in 30 days = 30 × 24 × 60 = 43,200
  • Budget in minutes = 43,200 × 0.001 = 43.2 minutes (about 43 minutes 12 seconds per month; often rounded to ~43.8 minutes when quoted per average calendar month of 30.44 days)
If the service has already had a 20-minute outage this window, roughly 23 minutes of budget remain. A second incident of similar size would nearly exhaust it. For a request-based SLO the same logic applies to counts: at 99.9% success over 10 million monthly requests, the budget is 10,000 failed requests.

​
What is burn rate?

Burn rate measures how fast you are consuming the budget relative to the pace that would exactly exhaust it at the end of the window:
A burn rate of 1 means you will land exactly on budget. A burn rate of 14.4 against a 30-day, 99.9% SLO means the entire month’s budget will be gone in about 50 hours. Burn rate is the basis for modern SLO alerting. Instead of paging on raw error percentages, teams page on fast burn (e.g., a high burn rate sustained for an hour — something is actively wrong) and ticket on slow burn (a modest burn rate sustained for days — reliability is quietly eroding). This keeps pages tied to real budget impact rather than momentary blips.

​
What is an error budget policy?

An error budget policy is a pre-agreed document that says what happens as the budget depletes. Deciding this in advance — before anyone is angry — is the whole point. A typical policy might look like: The policy is a contract between product and engineering. Product gets a guarantee that reliability work won’t be invoked arbitrarily to block launches; engineering gets an objective trigger for prioritizing stability that doesn’t depend on winning an argument.

​
How do error budgets relate to SLOs?

An error budget is simply an SLO viewed from the other side. The SLO states the reliability floor (“99.9% of requests succeed”); the error budget states the failure allowance that floor implies (“0.1% may fail”). This reframing does two useful things:
  1. It makes reliability spendable. Instead of treating every incident as a moral failure, teams treat downtime as a resource: spend it on velocity when the budget is healthy, conserve it when it isn’t.
  2. It acknowledges that 100% is the wrong target. Users cannot tell the difference between 99.999% and 100%, but the engineering cost of chasing the last fraction is enormous. The budget makes that trade-off explicit.
Error budgets only work when the underlying SLO is measured from a well-chosen SLI and set at a level users actually need — see SLA vs SLO vs SLI for how the three fit together. Rootly’s incident data feeds budget tracking naturally: incident duration and severity metrics (see default metrics) show exactly which incidents consumed the budget and where reliability effort should go next. Browse the full incident management glossary.