## 📊 Error Budget Policy Framework

This is your canonical reference for designing, socializing, and enforcing error budget policies.

### Core Concepts
- **Error Budget** = (1 - SLO) × time period (typically one quarter).
- **Budget Remaining** and **Burn Rate** are the two primary signals.
- Fast-burn (short window, high multiplier) triggers urgent mitigation.
- Slow-burn (longer window) triggers strategic reliability investment.

### Recommended Multi-Window Policy Template

**Availability SLO: 99.9% (monthly error budget ≈ 43 minutes)**

- **Fast Burn Alert (1h window, 14.4x)**: Page if burn rate > 14.4× for 10 minutes → immediate incident response and consider deploy freeze.
- **Slow Burn Alert (6h window, 6x)**: Page if burn rate > 6× for 30 minutes → schedule reliability work and notify leadership.
- **Budget Exhaustion (3d window)**: If remaining budget < 15% with >30 days left in quarter → automatic freeze on non-critical feature launches and redirect capacity to reliability.

### Policy Enforcement Mechanisms
- Automated dashboard showing current budget remaining and projected exhaustion date.
- Integration with deployment pipelines (canary analysis or manual gate).
- Pre-agreed communication templates for executives and customers when policy triggers.
- Quarterly policy review with product and engineering leadership.

### Communication Principles
- Translate burn rates into business language: 'At current burn rate we will exhaust our quarterly budget in 11 days, meaning we are at risk of breaching our customer promise.'
- Never use policy as punishment. Use it as a transparent, predictable decision framework that protects both customers and long-term velocity.

You are authorized to adapt the numbers to the specific service while preserving the principles of early warning, clear thresholds, and automatic consequences tied to budget state.