Burn Rate Calculator
Generate multi-window burn rate alert thresholds for any SLO. Get the canonical Google SRE Workbook windows and a copy-paste Prometheus alert rule.
Used as the metric label in the Prometheus rule below.
Multi-window alert thresholds for 99.9% SLO
| Severity | Long | Short | Burn Rate | Error Rate Threshold | Budget Consumed | Time to Detect |
|---|---|---|---|---|---|---|
| PAGE | 1h | 5m | 14.4× | > 1.44% | 2% of monthly | 5m |
| PAGE | 6h | 30m | 6× | > 0.600% | 5% of monthly | 30m |
| TICKET | 1d | 2h | 3× | > 0.300% | 10% of monthly | 120m |
| TICKET | 3d | 6h | 1× | > 0.100% | 10% of monthly | 360m |
A multi-window alert fires only when both the long and short windows exceed the threshold, which prevents flapping while keeping detection fast.
Prometheus Alert Rule
groups:
- name: my-service-slo-burn-rate
rules:
- alert: MyserviceSLOBurnPage1h
expr: |
(
sum(rate(http_requests_total{service="my-service",status=~"5.."}[1h]))
/ sum(rate(http_requests_total{service="my-service"}[1h])) > 1.440e-2
) and (
sum(rate(http_requests_total{service="my-service",status=~"5.."}[5m]))
/ sum(rate(http_requests_total{service="my-service"}[5m])) > 1.440e-2
)
for: 2m
labels:
severity: page
slo: "99.9"
annotations:
summary: "my-service burning SLO budget at 14.4x ideal rate"
description: "Error rate over 1h exceeds 1.440e-2 (error budget = 1.00e-3, burn rate = 14.4x)"
- alert: MyserviceSLOBurnPage6h
expr: |
(
sum(rate(http_requests_total{service="my-service",status=~"5.."}[6h]))
/ sum(rate(http_requests_total{service="my-service"}[6h])) > 6.000e-3
) and (
sum(rate(http_requests_total{service="my-service",status=~"5.."}[30m]))
/ sum(rate(http_requests_total{service="my-service"}[30m])) > 6.000e-3
)
for: 2m
labels:
severity: page
slo: "99.9"
annotations:
summary: "my-service burning SLO budget at 6x ideal rate"
description: "Error rate over 6h exceeds 6.000e-3 (error budget = 1.00e-3, burn rate = 6x)"
- alert: MyserviceSLOBurnTicket1d
expr: |
(
sum(rate(http_requests_total{service="my-service",status=~"5.."}[1d]))
/ sum(rate(http_requests_total{service="my-service"}[1d])) > 3.000e-3
) and (
sum(rate(http_requests_total{service="my-service",status=~"5.."}[2h]))
/ sum(rate(http_requests_total{service="my-service"}[2h])) > 3.000e-3
)
for: 2m
labels:
severity: ticket
slo: "99.9"
annotations:
summary: "my-service burning SLO budget at 3x ideal rate"
description: "Error rate over 1d exceeds 3.000e-3 (error budget = 1.00e-3, burn rate = 3x)"
- alert: MyserviceSLOBurnTicket3d
expr: |
(
sum(rate(http_requests_total{service="my-service",status=~"5.."}[3d]))
/ sum(rate(http_requests_total{service="my-service"}[3d])) > 1.000e-3
) and (
sum(rate(http_requests_total{service="my-service",status=~"5.."}[6h]))
/ sum(rate(http_requests_total{service="my-service"}[6h])) > 1.000e-3
)
for: 2m
labels:
severity: ticket
slo: "99.9"
annotations:
summary: "my-service burning SLO budget at 1x ideal rate"
description: "Error rate over 3d exceeds 1.000e-3 (error budget = 1.00e-3, burn rate = 1x)"Replace http_requests_total and the error filter with your own metric. The rule assumes a request-success SLI; adapt for latency or other SLI types as needed.
Automate your incident response
Reduce MTTR by 90% with AI-powered root cause analysis. Free to start.
Why multi-window burn rate alerting
Traditional alert thresholds ("page if error rate > 1% for 5 minutes") suffer from two problems. They flap on transient blips, and they are decoupled from how much of your error budget you can actually afford to spend. Burn rate alerts solve both: by tying the threshold directly to the SLO, every alert means "you are spending budget too fast," which is the only thing that actually matters.
The multi-window pattern adds a second sanity check: the alert fires only if a longer window also exceeds the threshold. That filters out flapping while keeping fast detection for real incidents.
The four canonical windows
Google’s SRE Workbook recommends four alert windows tuned to consume a well-defined slice of monthly error budget before firing.
- 14.4× over 1 hour — fastest page. Fires when an outage is severe enough to consume 2% of monthly budget in a single hour.
- 6× over 6 hours — slower page. Catches sustained incidents that escape the 1-hour detector.
- 3× over 1 day — ticket-level slow burn. Real issue, but not an immediate page.
- 1× over 3 days — background burn. Useful for catching long-tail reliability degradation.
From alerts to automation
Burn rate alerts tell you the budget is at risk. Reducing the time it takes to investigate and resolve the underlying incident is what actually saves the budget. Uptimes.ai automatically correlates alerts across Datadog, Prometheus, and PagerDuty, runs an AI-driven root cause investigation in under three minutes, and can execute pre-approved remediations — turning a 30-minute incident into a sub-minute one.