Service Level Indicators (SLIs), Objectives (SLOs), and Error Budgets

In Site Reliability Engineering, reliability is not 100%. 100% uptime is impractical, cost-prohibitive, and halts innovation velocity. Instead, SRE manages reliability mathematically using SLIs (What you measure), SLOs (Your internal target), and Error Budgets (The acceptable margin of failure).

⚡ Quick Dive

SLI vs. SLO vs. SLA vs. Error Budget Rosetta Stone

Term Full Name Definition Example / Target
SLI Service Level Indicator Quantifiable metric measuring service health Successful HTTP requests / Total HTTP requests
SLO Service Level Objective Internal target threshold for an SLI over a rolling window 99.9% of requests respond successfully over 30 days
SLA Service Level Agreement Legal contract with customers with financial penalties 99.5% uptime (Credit issued if breached)
Error Budget Acceptable Failure Allowance $100% - \text{SLO}$ budget used for shipping risky features $0.1% \text{ allowable errors} \approx 43.2\text{ minutes downtime/month}$

The "Nines" of Availability (Downtime per Time Window)

Target Availability Downtime per Month (30 Days) Downtime per Year (365 Days) Error Budget (Monthly)
99% ("Two Nines") 7.2 hours 3.65 days 1%
99.9% ("Three Nines") 43.2 minutes 8.76 hours 0.1%
99.95% 21.6 minutes 4.38 hours 0.05%
99.99% ("Four Nines") 4.32 minutes 52.56 minutes 0.01%
99.999% ("Five Nines") 25.9 seconds 5.26 seconds 0.001%

📖 Extended Guide

1. Error Budget Policies: Balancing Velocity and Reliability

              ┌──────────────────────────────────────────────┐
              │ Is Error Budget Remaining? (> 0%)            │
              └──────────────────────┬───────────────────────┘
                                     │
                 ┌───────────────────┴───────────────────┐
                 ▼ (YES)                                 ▼ (NO - Budget Exhausted!)
┌──────────────────────────────────┐    ┌──────────────────────────────────┐
│ Feature Velocity Unconstrained   │    │ FEATURE FREEZE INITIATED         │
│ - Ship experiments & new code    │    │ - Deployments halted             │
│ - Run chaos experiments & load   │    │ - 100% focus on stability, bugs, │
│   tests safely                   │    │   monitoring & reliability debt  │
└──────────────────────────────────┘    └──────────────────────────────────┘

2. Multi-Window Multi-Burn-Rate Alerting

Traditional threshold alerts (e.g. "alert if error rate > 1%") cause alert fatigue during brief spikes or fail to page on slow, steady degradation. Burn Rate Alerting fires based on how fast the error budget is being consumed:

$$\text{Burn Rate} = \frac{\text{Observed Error Rate}}{1 - \text{SLO}}$$

  • A Burn Rate of 1 consumes 100% of the monthly error budget in exactly 30 days.
  • A Burn Rate of 14.4 consumes 100% of the budget in 2 days (requires immediate page).
⌂ All Guides