Error Budget Explained: Formula, Burn Rate & Worked Example

Error budgets are the core mechanism that makes Google’s Site Reliability Engineering (SRE) work. They answer the question every engineering team faces: “How much risk can we take when shipping changes?”

The Core Idea

An error budget is the maximum amount of unreliability your service can tolerate before you’ve violated your SLO. It’s calculated simply:

Error Budget = 1 - SLO target

If your SLO is 99.9% availability, your error budget is 0.1%. Over a 30-day month (43,200 minutes), that’s 43.2 minutes of allowed downtime.

Use the error budget calculator to compute your specific budget and burn rate.

Worked example: a 30-day time-based budget

At 99.9%, the allowed downtime is 43.2 minutes. If you measured 12 minutes of downtime using the same definition and window, you have 31.2 minutes left: about 72.2% of the original budget. Unknown observation periods must remain unknown rather than being counted as healthy.

For a request-based SLO, use failed requests and total requests instead of minutes. A synthetic HTTP check samples availability from its observer; it is not a census of customer requests.

Warden can provide endpoint checks, failure evidence and response-time degradation alerts. It does not currently provide automatic contractual SLA reports or native multi-window error-budget alerting. Try a monitor or choose managed Warden and keep request-level SLO accounting in your telemetry system.

Why Error Budgets Work

Without error budgets, reliability and feature development are in constant tension. The product team wants to ship fast; the ops team wants to change nothing. Error budgets resolve this by making the trade-off explicit and data-driven.

When budget is available: Ship aggressively. Deploy frequently. Take calculated risks. The SLO gives you permission to be imperfect.

When budget is low or exhausted: Slow down. Focus on reliability. Fix flaky tests. Improve monitoring. Reduce deployment risk.

This isn’t a punishment. It’s a rational response to data. The budget is spent, so the investment shifts from features to reliability until it recovers.

How Google Uses Error Budgets

Google’s SRE teams operate with these principles:

1. SLOs are the source of truth

Not uptime targets pulled from thin air, but carefully chosen targets based on user expectations and business needs.

2. The budget belongs to the product team

The product team “spends” the error budget by deploying changes that might cause instability. They own the budget, so they own the decision of when to spend it.

3. When the budget is exhausted, SRE takes over

If the error budget is consumed, SRE can freeze non-critical deployments, require more stringent testing, or mandate reliability improvements before new features ship.

4. Excess budget is intentional

An unused budget is not a reason to cause failures. Review whether the target reflects user needs and whether the team can safely increase its delivery pace.

Calculating Burn Rate

Burn rate measures how fast you’re consuming your error budget relative to what’s sustainable.

Burn Rate = Actual error rate / Allowed error rate

• Burn rate = 1x → Consuming budget at exactly the sustainable rate. You’ll exhaust it at the end of the window
• Burn rate = 10x → Consuming 10x too fast. Budget exhausted in 1/10th of the window
• Burn rate = 0.5x → Under budget. You have room for more risk

Multi-Window Alerting

For a 30-day SLO, one example uses a 14.4× threshold over both 1 hour and 5 minutes, and a second uses 6× over both 6 hours and 30 minutes. Each pair checks sustained impact and recent activity. Implement these against the same SLI and handle missing data explicitly. See Google’s SRE workbook for the complete design and low-traffic considerations.

Setting Your SLO

Your SLO should balance user expectations with engineering cost:

1. Measure current reliability — Track your actual availability for 2-4 weeks before setting a target
2. Understand user tolerance — Ask which workflows are critical and how interruptions affect them; 99.9% is an example, not a universal requirement
3. Consider dependencies — Model redundancy, shared failures and fallback behavior. A provider SLA is a contractual commitment, not a hard ceiling on measured availability
4. Start conservative — Choose an internal target you can justify with measurements before offering contractual commitments

Error Budget Policies

Document what happens at different budget levels:

The specific thresholds and policies should be agreed upon by product and engineering leadership before they’re needed. Negotiating during a crisis leads to bad decisions.

Common Mistakes

1. Setting SLOs too high — A target unsupported by user needs, architecture and operating capacity can crowd out other useful work
2. No consequences for exhaustion — An error budget without enforcement is just a number
3. Measuring the wrong SLI — Uptime alone misses latency degradation and partial failures
4. Monthly windows only — Consider rolling windows (last 30 days) instead of calendar months to avoid month-boundary gaming
5. Not reviewing SLOs — Review quarterly. Adjust based on user feedback and business needs

Getting Started

You don’t need to be Google to use error budgets:

1. Define one SLI (e.g., “homepage returns 200 in under 2 seconds”)
2. Set an SLO (e.g., “99.9% over 30 days”)
3. Calculate the budget (0.1% = 43 minutes/month)
4. Monitor it with appropriate frequency
5. Track consumption and adjust deployment pace accordingly

The error budget calculator handles the math. The hard part is the organizational discipline to actually follow through.

Related tools:

• Error Budget Calculator — Calculate budget, burn rate, and exhaustion time
• Uptime Calculator — Convert SLO targets to downtime allowances
• Downtime Cost Calculator — Quantify the business impact when budgets are exceeded