How do I pick fast/slow burn thresholds?

Start with Google SRE’s guidance: for 99.9% availability, alert when 5m burn >14x AND 1h burn >7x. Adjust per tier. Tier 2 can tolerate lower thresholds (e.g., 8x/2x). Watch for paging volume for two weeks and tune.

What if dependencies blow my budget?

Create dependency SLOs and carve out steady-state budget. Escalate with evidence: show the burn attributed to the dependency. Add circuit breakers/timeouts and consider caching or degradation paths so their pain doesn’t become your burn.

We’re a small team. Is this overkill?

You can do a lightweight version: a single availability SLO + a p99 threshold, one multi-window alert, and a canary gate in Argo Rollouts. It’s a day or two of work and it stops most self-inflicted incidents.

Where do feature flags fit?

Treat flags like deploys. Tag traces/logs with active flags, and wire kill switches to the same burn metrics. Auto-disable high-risk flags on Tier 0 when burn spikes.

Can I do this without Kubernetes?

Yes. Use Prometheus/Alertmanager or CloudWatch alarms for burn, route to PagerDuty, and integrate with your deploy system (Spinnaker, Jenkins, GitHub Actions). The pattern is tooling-agnostic.

Reliability-observability · Dec 10, 2025 · 10 minute read

Error Budgets By Tier: Stop Letting One Noisy Service Burn Your Whole Quarter

Design error budget allocation that predicts incidents, gates rollouts, and makes triage boring — not political.

Back to all posts

Error Budgets By Tier: Stop Letting One Noisy Service Burn Your Whole Quarter

Key takeaways

Implementation checklist