What Is an Error Budget?

Last verified on Nov 8, 2026.

An error budget turns an SLO into an amount you can spend. It is the share of requests, or minutes, that are allowed to fail in a window while you still meet your target. Spend it on risky releases, experiments, and the occasional bad day. When it is gone, reliability work moves to the front of the queue.

The Formula

error budget = 100% - SLO
allowed bad events = total events in window x (1 - SLO)

Google's workbook gives the standard example. A 99.9% success-ratio SLO over four weeks, with 3 million requests, leaves a budget of 3,000 (0.1%) errors. If one outage causes 1,500 errors, it cost half the budget.

The same arithmetic works for time. A 99.9% SLO over 30 days allows 43.2 minutes of full downtime. The budget is a count, so partial failures count in proportion: a 10-minute outage that failed half of all requests used 5 minutes of it.

Where the Idea Comes From

The SRE book introduces the budget as a way to settle an old argument. Product teams want to ship, and reliability teams want stability. Rather than negotiate every launch, both sides agree on an SLO. The monitoring system measures actual reliability, and the gap between the two is what is left to spend. As long as budget remains, releases continue.

The book's worked example: a 99.999% SLO means a failure rate budget of 0.001% per quarter. A problem that fails 0.0002% of expected queries spends 20% of it.

The book also notes that this makes teams self-policing. When the budget is large, developers can take risks. When it is nearly gone, they push for more testing themselves, because they do not want to stall their own launch. That outcome depends on the reliability team having the authority to stop launches.

Putting Numbers on Incidents

Because the budget is a count, you can price any incident against it. The workbook's example: a bad API release causes 100% errors for four hours, with 14,066 errors in the server logs. Against a 97% SLO with a budget of 109,897 errors, that single event used 13% of the budget.

This tells you where to invest. If bad releases cost twice as much budget as hardware failures, hardening deployments beats buying redundancy. To price an incident from logs, count failing events in the incident window and divide by the budget:

SELECT count(*) FILTER (WHERE status >= 500) AS bad_events,
       count(*) FILTER (WHERE status >= 500)::float / (0.001 * 3000000) AS share_of_budget
FROM request_logs
WHERE ts BETWEEN '2026-11-02 09:10' AND '2026-11-02 09:40';

Replace 0.001 * 3000000 with your own allowed-failure count for the window.

Burn Rate and Alerting

Burn rate measures how fast you are spending. A burn rate of 1 uses exactly the whole budget by the end of the window. A burn rate of 10 empties it in a tenth of the window.

Google's workbook recommends alerting on burn rate over two windows at once: a long one to confirm the problem is real, and a short one so the alert resets quickly when it ends. Its recommended starting point for a 99.9% SLO:

The logic is that a fast burn needs a human now, and a slow burn can wait for working hours. The workbook also warns that low-traffic services need a different approach. Ten requests an hour make one failure a 10% error rate, which against a 99.9% SLO is a 1,000x burn rate.

An Error Budget Policy

A budget with no rules is a dashboard. The workbook's example policy is short and worth copying as a starting point:

• If the service is within SLO, releases proceed as normal.
• If the four-week budget is exceeded, halt changes other than top-priority fixes and security patches until the service is back within SLO.
• If a single incident takes more than 20% of the four-week budget, hold a postmortem with at least one top-priority action item.
• If one class of outage takes more than 20% over a quarter, put a fix on the next quarter's plan.

The policy also lists when feature work may continue anyway: the outage came from a company-wide network failure, a dependency owned by a team that has itself frozen releases, or load testers using up the budget.

Pitfalls

• Counting the wrong things. The example policy says miscategorized errors can consume or spare budget wrongly. Define which failures count when you write the SLI.
• Targets that cannot be hit. An SLO that leaves no budget makes the idea pointless.
• Hiding slow burns. Quiet regressions can add up. Look at performance degradation and latency drift as well as hard errors, and see Sazabi's reliability issue detection.