SLOs: Advanced Strategies

Multi-window SLO: a 30-day rolling window smooths short outages, potentially hiding a 2-hour outage that consumes a significant chunk of error budget. Adding a 1-hour window triggers alerts for sharp reliability drops. Google SRE recommends the 5%-burn-rate-for-1-hour and 2%-burn-rate-for-6-hour multi-burn-rate alerting model.

Error budget policy: without a policy, an exhausted error budget is just a number. The policy gives it teeth: engineering leadership agrees upfront that at 75% budget consumption, the on-call team can block feature deployments. This creates a shared incentive — product teams want to ship features, operations wants reliability, and the policy balances them.

Burn rate: if your 30-day SLO is 99.9% (0.1% error budget), a burn rate of 14.4 means you're consuming the entire monthly budget in 2 hours (30 days / 14.4). Multi-burn-rate alerts: page immediately at high burn rate, ticket at low sustained burn rate — balancing alert fatigue against missing slow degradation.

SLO vs SLA: you set your internal SLO at 99.9% and commit in an SLA to 99.5%. The gap is the safety buffer — if your error budget runs low, you can take corrective action before breaching the SLA and triggering financial penalties or customer credits. SLOs are the day-to-day engineering target.

Burn rate alerting: a static threshold of "alert if error rate > 0.1%" fires constantly during normal spikes. A burn rate alert fires only when errors are consuming the budget fast enough to exhaust it within a meaningful timeframe. This reduces alert fatigue while ensuring real reliability problems get attention.