DevOps & Reliability Engineering

SLO & Error Budget Multi-Window Burn-Rate Calculator

Google SRE Multiwindow Multi-Burn-Rate alerting calculator. Model downtime, error budget depletion velocity, and export production Prometheus Alertmanager rules & Grafana PromQL.

SLO Parameters

99.9%

~1296.0M total requests in 30 days

0.25%
0% (Perfect)2.5%5.0% (Severe)
Error Budget
0.100%
1,295,999 allowed bad requests
Max Downtime
0h 43m 11s
Total allowed outage in 30d
Burn Rate
2.5x
Exhausts budget in 11d 23h

Google SRE Multi-Window Multi-Burn-Rate Matrix

Eliminates alert fatigue by requiring both short and long rolling windows to exceed the burn rate threshold.

Target: 99.9%
Alert SeverityBurn MultiplierLong WindowShort WindowBudget Impact
Critical (Page)14.4x1h5m2% budget in 1 hour
High (Page)6x6h30m5% budget in 6 hours
Medium (Ticket)3x1d2h10% budget in 3 days
Low (Log)1x3d6h10% budget in 3 days
groups:
  - name: checkout-api-slo-burn-rate-alerts
    rules:
      # Critical Page (Fast Burn) (2% budget in 1 hour)
      - alert: checkout_api_SLOBurnRate_14_4x
        expr: |
          (
            rate(http_requests_total{status=~"5.."}[1h])
            /
            rate(http_requests_total[1h])
          ) > (14.4 * 0.00100)
          and
          (
            rate(http_requests_total{status=~"5.."}[5m])
            /
            rate(http_requests_total[5m])
          ) > (14.4 * 0.00100)
        for: 2m
        labels:
          severity: critical
          slo_target: "99.9%"
          service: "checkout-api"
        annotations:
          summary: "High error budget burn rate (14.4x) for checkout-api"
          description: "Service checkout-api is burning its 30-day error budget at 14.4x (threshold: >0.01440). Consuming 2% budget in 1 hour."

      # High Severity Page (Moderate Burn) (5% budget in 6 hours)
      - alert: checkout_api_SLOBurnRate_6x
        expr: |
          (
            rate(http_requests_total{status=~"5.."}[6h])
            /
            rate(http_requests_total[6h])
          ) > (6 * 0.00100)
          and
          (
            rate(http_requests_total{status=~"5.."}[30m])
            /
            rate(http_requests_total[30m])
          ) > (6 * 0.00100)
        for: 2m
        labels:
          severity: critical
          slo_target: "99.9%"
          service: "checkout-api"
        annotations:
          summary: "High error budget burn rate (6x) for checkout-api"
          description: "Service checkout-api is burning its 30-day error budget at 6x (threshold: >0.00600). Consuming 5% budget in 6 hours."

      # Medium Ticket (Slow Burn) (10% budget in 3 days)
      - alert: checkout_api_SLOBurnRate_3x
        expr: |
          (
            rate(http_requests_total{status=~"5.."}[1d])
            /
            rate(http_requests_total[1d])
          ) > (3 * 0.00100)
          and
          (
            rate(http_requests_total{status=~"5.."}[2h])
            /
            rate(http_requests_total[2h])
          ) > (3 * 0.00100)
        for: 2m
        labels:
          severity: warning
          slo_target: "99.9%"
          service: "checkout-api"
        annotations:
          summary: "High error budget burn rate (3x) for checkout-api"
          description: "Service checkout-api is burning its 30-day error budget at 3x (threshold: >0.00300). Consuming 10% budget in 3 days."

      # Low Warning (Drift) (10% budget in 3 days)
      - alert: checkout_api_SLOBurnRate_1x
        expr: |
          (
            rate(http_requests_total{status=~"5.."}[3d])
            /
            rate(http_requests_total[3d])
          ) > (1 * 0.00100)
          and
          (
            rate(http_requests_total{status=~"5.."}[6h])
            /
            rate(http_requests_total[6h])
          ) > (1 * 0.00100)
        for: 2m
        labels:
          severity: warning
          slo_target: "99.9%"
          service: "checkout-api"
        annotations:
          summary: "High error budget burn rate (1x) for checkout-api"
          description: "Service checkout-api is burning its 30-day error budget at 1x (threshold: >0.00100). Consuming 10% budget in 3 days."

Why Single-Window Burn Rate Alerts Fail in Production

Traditional alerts check a single rolling window (e.g. 5 minutes). If a brief traffic spike causes 50 errors in 1 minute, a 5-minute alert fires and wakes up the engineer, even if the system has already recovered. Conversely, a 30-day alert takes days to notice a severe 5% regression.

Google SRE’s Multi-Window Multi-Burn-Rate methodology requires that both a short window (e.g. 5 minutes) and a long window (e.g. 1 hour) simultaneously breach the burn rate threshold. This guarantees near-zero alert reset latency while completely eliminating false positives from ephemeral network blips.

Advertisement

How to use

  1. 1Select your target Service Level Objective (e.g. 99.9% or 99.95%) and compliance window (e.g. 30 days).
  2. 2Enter your average traffic throughput in requests per second (RPS) to calculate absolute allowed bad requests.
  3. 3Simulate current error rates to visualize burn rate multipliers and time-to-exhaustion.
  4. 4Copy the generated Prometheus Alertmanager YAML or Grafana PromQL queries directly into your observability infrastructure.

Frequently asked questions

What is a Multiwindow Multi-Burn-Rate Alert?
Multiwindow Multi-Burn-Rate alerting is the Google SRE standard for monitoring Service Level Objectives (SLOs). It evaluates both a long window (e.g. 1 hour) and a short window (e.g. 5 minutes) simultaneously. This prevents alert fatigue from short ephemeral spikes while ensuring fast response times when an outage occurs.
How is the Burn Rate Multiplier calculated?
Burn Rate is the ratio of your current observed error rate to your maximum allowed error rate. For a 99.9% SLO, your allowed error rate is 0.1%. If your service experiences a 1.44% error rate, your burn rate is 1.44 / 0.1 = 14.4x, consuming 2% of your monthly budget in 1 hour.
How much downtime is allowed for 99.9% vs 99.99% availability?
Over a 30-day compliance period, a 99.9% SLO permits 43 minutes and 12 seconds of total unavailability. A 99.99% ("four nines") SLO permits only 4 minutes and 19 seconds of total downtime across the entire month.
Why should I alert on error budget burn rate instead of raw CPU or error counts?
Raw thresholds (like "500 errors > 100") fire constantly during high-traffic surges even when user success rate is 99.99%, or fail to fire during low-traffic nights when 100% of users are failing. SLO burn rate alerts directly measure actual user pain and business impact.

The Senior Full-Stack Production Kit (2026)

Checklists, Docker recipes, and SSR error fixes in one dense PDF.

Get Free Kit

Related articles

ToolsTagsRSSPrivacy PolicyTerms