Error Budget Calculator
See how much of your error budget is left for an SLO and period, with a suggested operating action.
Formula last reviewed 4 August 2026 · How we verify our calculators
Error budget remaining
- Budget consumed
- 50.0%
- Total allowed failures
- 3,000
- Failures still allowed
- 1,500
- Within budget?
- Yes — compliant
- Suggested action
- Ship normally
Updates live as you type
Frequently asked questions
The budget in events is total requests × (100 − SLO) ÷ 100. At 99.9% over 3,000,000 requests, that is 3,000 allowed failures. Consumed % is your actual failures ÷ that budget.
The pre-filled values reproduce the SRE workbook: with a 3,000-error budget, a single outage causing 1,500 errors consumes exactly 50% of the budget for the period.
It is an agreed set of actions tied to how much budget remains — for example, freezing features when the budget runs low. The suggested actions here are a common pattern, not a universal rule; adapt the thresholds to your team’s risk tolerance.
By convention, teams halt risky changes and redirect effort to reliability until the budget recovers over the next window. The point is to make the trade-off between velocity and reliability explicit, not punitive.
The error budget is an internal mechanism derived from your SLO. An SLA is the external contract; you want to spend the error budget well before the SLA is ever threatened.
How much of your error budget is left?
An error budget is the flip side of an SLO: if your objective is 99.9% success, you are explicitly allowing 0.1% failure. This calculator turns that into concrete numbers — how many failures you may have in the period, how many you've used, what fraction remains, and a suggested operating action.
The inputs are pre-filled with the canonical Google SRE workbook example so you see a known-correct result immediately: a 99.9% SLO over 3,000,000 requests gives an allowed-failures budget of 3,000,000 × 0.001 = 3,000 events. A single outage causing 1,500 failures then consumes 1,500 ÷ 3,000 × 100 = exactly 50% of that budget, leaving 1,500 failures still available and 50% remaining for the rest of the period — comfortably inside the "ship normally" band. Push actual failures up to 2,800 instead, and remaining budget shrinks to just 200 events (under 7%), which is exactly the kind of situation where the suggested action shifts toward tightening review or freezing risky changes. Change the numbers to match your own service's real request and failure counts.
The suggested action comes from an error-budget *policy* — a set of agreed responses tied to how much budget is left (ship normally when healthy; tighten review, then freeze features, then go all-in on reliability as it depletes). Treat the bands shown here as a common pattern, not a universal rule — every team should set thresholds that match its own appetite for risk.
The value of running reliability this way is that it replaces arguments about "is the service reliable enough?" with a shared, quantitative budget. Velocity and reliability stop being in vague tension and become a single number everyone can see. For tracking how *fast* you're spending the budget, pair this with the burn-rate calculator.
Sources
- Google SRE Workbook — error budget worked example (99.9% SLO, 3,000,000 requests)