SLO Calculator + Burn-Rate Alerts

What's an SLO and why should you have one?

The most-confused triad in SRE is also the most foundational. An SLA (Service Level Agreement) is a contract with a customer — when you miss it, you owe them something concrete: a refund, a credit, a public post-mortem. An SLO (Service Level Objective) is the internal target your team commits to — when you miss it, you change priorities, freeze risky work, redirect engineering to reliability. An SLI (Service Level Indicator) is the actual measurement: request success rate, latency percentile, queue depth.

SLOs matter because they create a shared language for "is this service healthy enough?" that survives team turnover and product pressure. Instead of arguing about whether 27 alerts last week were too many, the team can ask: did we burn the error budget? If yes, slow down. If no, keep shipping.

The inverse of the SLO is the error budget: the amount of failure you're allowed before action. A 99.9% SLO over 30 days is a 0.1% budget — about 43 minutes of downtime. That budget is what you spend on deploys, experiments, planned maintenance, and the inevitable surprises. When it runs out, the team's options change.

How burn-rate alerting works

The naive approach to alerting on SLOs is "page on every error." That generates noise, on-call burnout, and ignored alerts the day you actually need them. The error-budget approach inverts the question: don't ask whether any errors happened; ask whether they're happening fast enough to matter.

Pick a budget consumption rate that should fire a page — say, 2% of monthly budget in 1 hour. The error rate corresponding to that consumption is your alert threshold. If the running 1-hour error rate exceeds the threshold, you're burning fast and someone needs to know now. If it doesn't, the system is fine even if some users are seeing errors.

The trick that makes burn-rate alerts quiet as well as responsive is the multi-window check. Each alert is a conjunction of two conditions — a long window (1 hour) confirms "is this real?" and a short window (5 minutes) confirms "is it still happening?" Without the short-window check, you keep paging during recovery. Without the long-window check, you page on every twitch. Both together: you page on sustained problems that are still active, and the alert silences itself when the situation recovers.

Concrete walkthrough for the canonical 14.4× / 1h / 5m alert at 99.9% SLO:

• Error rate threshold: 14.4 × 0.001 = 0.0144 (i.e., a 1.44% error rate)
• If the 1-hour error rate > 1.44% and the 5-minute error rate > 1.44%, fire the alert
• 14.4× × 1h / 720h = 2% of the 30-day budget consumed during this hour
• The reason 14.4 isn't a round number: it's the multiplier that produces "2% in 1h" exactly

Tuning burn-rate thresholds

The four rules in the canonical recipe — fast burn at 1h, sustained fast burn at 6h, slow burn at 24h, very slow burn at 3d — cover the realistic ways an SLO gets violated. Every team starts there. The variants below are calibrations, not replacements.

• Conservative is the right starting point for most teams. Pages on real problems, files tickets on slow burns. The 1× / 3d ticket alert is intentional: even a tiny sustained drift will eventually consume the budget, and 3 days is the right horizon to do something about it.
• Recommended tightens the warning thresholds (2× over 24h, 0.5× over 3d) for teams getting too much warning-tier noise. The reasoning: at 30-day windows, the canonical 3× ticket alert often fires after the team has already noticed via dashboards or customer reports; tighter thresholds page later but more reliably.
• Aggressive halves the long windows on fast burns (30m, 2h) for high-criticality services running 99.99%+, where 1h to detect is too slow. Trade-off: more sensitivity to short bursts.
• Custom is for batch jobs and other non-request-rate workloads where the canonical windows don't fit naturally.

The thing not to do: tune thresholds to silence pages. Threshold tuning is for calibration, not avoidance. If you're paging too often on a service, the answer is to fix the underlying reliability or rethink the SLO target — not to widen the alert windows until the same incident no longer trips them.

Composite SLOs and dependency math

Real services depend on other services. When yours depends on N upstream APIs and any one of them failing means your request fails, the effective SLO is the product of the upstreams: 0.999 × 0.9995 = 0.9985005, or 99.85%. Five sequential 99.9% dependencies cap your achievable SLO at 99.5%. This is why architects sketching out a service tree have to think carefully about dependency depth.

Parallel composition is the inverse: when redundant replicas mean any one succeeding is enough, the effective unavailability is the product of unavailabilities, and the SLO improves super-linearly. Two 99% replicas in parallel give you 99.99%; three give you 99.9999%.

Practical implication: if your service depends on 4 external APIs at 99.9% each, you can't realistically claim 99.9% — the math caps you at 99.6%. Either absorb the risk into your published SLO (claim 99.5%), invest in redundancy (multiple providers, fallback paths), or pick the dependencies more carefully.

SLO anti-patterns

The 100% target

Impossible — and even attempting it wastes effort. The cost of going from 99.9% to 99.99% is roughly 10× the cost of the original 99.9%; from 99.99% to 99.999% is another 10×. Pick the SLO that customers actually need, not the highest number you can imagine. A 99.9% SLO covers most internal tools; 99.95% is the sweet spot for consumer-facing reads; 99.99% is for transactional systems where downtime is genuinely expensive.

Alerting on every error

Without burn-rate awareness, every failed request becomes a page. Teams burn out within a quarter, alerts get ignored, the next real incident hits an exhausted on-call rotation. The point of an SLO is that you've already decided what level of failure is tolerable — the alerting should match.

Window too long

90-day windows hide acute incidents inside budget noise. A two-hour outage is barely visible against a 90-day budget; the same outage shows up clearly against 7 or 30 days. 30 days is the sweet spot for most services. 7 days fits very high-traffic services where individual incidents are consequential.

Confusing SLO with SLA

SLA is for customers; SLO is for engineering. Don't share SLO numbers externally — share SLA numbers, which should be more conservative. The point of the gap is that you'd rather miss your internal SLO and learn about it than miss your SLA and owe someone money.

No error budget policy

What happens when the budget is burned? "Freeze deploys for the rest of the period." "No new feature work until the next window." "Incident review required for any new change." The policy is what makes the SLO actionable — without it, the SLO is just a report nobody reads.

FAQ