Error Budget & SLO Burn Rate
Calculate error budget consumption and burn rate from SLOs. Enter values for instant results with step-by-step formulas.
Formula
Burn Rate = (Budget Consumed %) / (Expected Consumption %)
Expected consumption is linear over the window (day 15 of 30 = 50%). Burn rate >1 means consuming faster than sustainable. Multi-window alerting catches both fast and slow burns.
Worked Examples
Example 1: Standard Web Service
Problem:SLO: 99.9%, 30-day window, 10M requests/month. Day 15: 5,000 failed requests, 30 min downtime.
Solution:Error Budget: 100% - 99.9% = 0.1% Requests: 10M × 0.1% = 10,000 allowed failures Time: 30 days × 1440 min × 0.1% = 43.2 min allowed Consumed: Requests: 5,000 / 10,000 = 50% Time: 30 / 43.2 = 69.4% Higher of two: 69.4% consumed Expected (day 15 of 30): 50% Burn rate: 69.4% / 50% = 1.39x Status: Elevated Days until exhausted: 30.6% / (69.4%/15) = 6.6 days
Result:1.39x burn rate (Elevated) | 69% consumed | 6.6 days until exhaustion
Example 2: Critical Payment API
Problem:SLO: 99.99%, 7-day window, 1M transactions. Day 3: 50 failures, 2 min downtime.
Solution:Error Budget: 100% - 99.99% = 0.01% Transactions: 1M × 0.01% = 100 allowed Time: 7 × 1440 × 0.01% = 1.01 min allowed Consumed: Transactions: 50 / 100 = 50% Time: 2 / 1.01 = 198% (OVER BUDGET!) Time-based exhaustion: 198% Budget exhausted - already over! Burn rate: 198% / 42.9% = 4.6x Status: Critical Action: Reliability freeze, incident review
Result:4.6x burn (Critical) | 198% consumed (OVER) | Budget exhausted
Example 3: Healthy Internal Service
Problem:SLO: 99.5%, 30-day window, 50M requests. Day 20: 100,000 failures, 60 min downtime.
Solution:Error Budget: 100% - 99.5% = 0.5% Requests: 50M × 0.5% = 250,000 allowed Time: 30 × 1440 × 0.5% = 216 min allowed Consumed: Requests: 100K / 250K = 40% Time: 60 / 216 = 27.8% Higher: 40% consumed Expected (day 20): 66.7% Burn rate: 40% / 66.7% = 0.6x Status: Excellent - Under budget! Opportunity: Can increase velocity, take on riskier changes
Result:0.6x burn (Excellent) | 40% consumed | Room for velocity
Frequently Asked Questions
What is an SLO?
Service Level Objective is a target reliability level, e.g., '99.9% of requests succeed.' SLOs should be customer-focused, measurable, and achievable. They're internal targets, unlike SLAs which are contractual commitments.
What is an error budget?
Error budget is the allowed failure rate derived from SLO. For 99.9% SLO, error budget is 0.1% of requests or ~43 minutes/month of downtime. It quantifies acceptable unreliability and balances reliability with velocity.
What is burn rate?
Burn rate measures how fast you're consuming error budget relative to expected pace. 1.0 = on track, 2.0 = twice as fast (will exhaust in half the window). High burn rates trigger alerts and may halt deployments.
How do I set SLO targets?
Base on user expectations and business needs. Start with current baseline, aim for achievable improvement. 99.9% is common for most services, 99.99% for critical infrastructure. Higher isn't always better - over-engineering wastes resources.
What happens when error budget is exhausted?
Common policies: freeze feature releases, redirect engineering to reliability work, require reliability review for any changes, increase testing requirements. Goal is to restore budget before resuming normal velocity.
How do I calculate downtime from SLO?
Monthly downtime = (100% - SLO%) × 43,200 minutes/month. 99.9% = 43.2 min/mo, 99.99% = 4.32 min/mo, 99.999% = 26 sec/mo. This assumes even distribution; incidents are typically clustered.
What are good SLO alert thresholds?
Google recommends multi-window alerting: 14.4x burn for 5-min window (page), 6x for 30-min (page), 3x for 6-hr (ticket), 1x for 3-day (ticket). This catches fast burns quickly while avoiding noise for slow burns.
How do SLIs, SLOs, and SLAs relate?
SLI (Indicator) = measurement (actual uptime %). SLO (Objective) = target (99.9% target). SLA (Agreement) = contract with consequences (credits if <99.9%). SLIs measure, SLOs target, SLAs commit.
Should I have multiple SLOs?
Yes, cover different aspects: availability (uptime), latency (p99 < 200ms), throughput, correctness. Don't have too many - 3-5 key SLOs per service. Each should reflect user-facing quality.
How do I implement error budgets?
1. Define SLIs and SLOs with stakeholders. 2. Instrument measurement (Prometheus, Datadog). 3. Create dashboards and alerts. 4. Establish policies for budget exhaustion. 5. Review monthly with all teams.