Alerting Strategy: SLOs, SLAs, and Error Budgets for Java Services
Fast recall
Quick revision
Core answer
Understanding of SRE reliability concepts and how they translate into concrete Prometheus alert rules for Java services.
Alerting on every error instead of sustained error budget burn rate, leading to alert fatigue.
Describe multi-window multi-burn-rate alerting (e.g., 5-minute and 1-hour windows) to catch both fast and slow burns before the budget is exhausted.
Interview-ready guide
Interview answer
SLO-based alerting changes the fundamental question from "is a metric above a threshold right now?" to "are we consuming error budget at a rate that will exhaust it before the end of the measurement period?" — which dramatically reduces alert noise while catching real reliability problems earlier.
SLI, SLO, SLA — the definitions
- SLI (Service Level Indicator) is the measurement — P99 latency, request success rate, availability; a specific, measurable signal from the service
- SLO (Service Level Objective) is the internal target — "99.9% of requests succeed" or "P99 latency < 300ms over a 30-day rolling window"; the level you're committing to maintain internally
- SLA (Service Level Agreement) is the external contract with consequences — fines, credits, or termination if the SLO is violated; most engineering teams work with SLOs, not SLAs directly
Error budget — the key concept
- An SLO of 99.9% allows 0.1% of requests to fail — in a month with 1 million requests, that's 1,000 allowed failures; the error budget is those 1,000 allowed failures
- If 800 failures occur in the first week, you've consumed 80% of the monthly budget in 25% of the time — the burn rate is 3.2x the sustainable rate, and you'll exhaust the budget by end of week 2
Multi-window burn rate alerting
- Alert when the burn rate is high over both short and long windows simultaneously —
burn_rate_1h > 14.4 AND burn_rate_6h > 6triggers when the recent hour is burning fast AND the trend is sustained - Fast burn (1h window, 14.4x burn rate) alerts on sudden catastrophic failures; slow burn (6h window, 6x) catches gradual degradation; both windows required to avoid false positives from transient spikes
Implementation in Prometheus
rate(http_server_requests_seconds_count{status=~"5.."}[5m]) / rate(http_server_requests_seconds_count[5m])is the error ratio; compare against the SLO threshold to compute burn rate- Google's "Alerting on SLOs" chapter in the SRE workbook provides the exact formulas for multi-window alerting
Alerting Strategy: SLOs, SLAs, and Error Budgets for Java Services
Direct Answer
Define SLIs (measurable signals like P99 latency and error rate), set SLOs (internal targets like 99.9% success rate), agree SLAs with customers, and use error budgets — the allowed margin of failure — to decide when to alert and when to stop feature work and focus on reliability.
Common Mistakes & Pitfalls
Alerting on every error instead of sustained error budget burn rate, leading to alert fatigue.
Check your understanding
Answer these without looking back at the article.
- What is the difference between a 99.9% SLO and 99.9% uptime?
- How do you handle scheduled maintenance windows in your error budget?
- What is multi-window multi-burn-rate alerting and why is it more effective?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.