Observability
SLO Burn Rate Alerting Guide
Design multi-window burn-rate alerts that detect fast outages and slow error-budget exhaustion without paging on every fluctuation. This reference is written for developers who need practical validation behavior, reviewable rules and safe examples rather than copied snippets with no explanation.
Recommended workflow
| Step | Why it matters |
|---|---|
| Define the SLI | Use a measurable good-event ratio tied to user experience. |
| Set the objective | The SLO determines the allowed error ratio and budget. |
| Pair windows | Combine short and long windows to require both urgency and sustained impact. |
| Tune with incidents | Backtest thresholds against known outages and harmless spikes. |
Starter snippet
burn rate = observed error ratio / allowed error ratioReview checks
- Exclude planned traffic only with documented policy.
- Use enough request volume for stable ratios.
- Link every page to a runbook.
- Track remaining budget outside alert state.
Common mistakes
- Alerting directly on monthly budget remaining.
- Using availability SLOs for latency failures.
- Paging on a short window with no confirmation window.
Validation should help users correct input while protecting systems from bad data. Keep syntax checks, product policy, security review and deliverability checks separate.
Related Formalint references
Continue with Error Budget Slo Guide, Prometheus Alert Rule Debugging, Uptime Monitoring Checklist.