Burn-Rate Alerting on SLOs: Fast and Slow Burn Config

Set up two alerting policies per SLO, not one. A fast-burn alert with a short lookback (1 to 2 hours) and a high threshold (around 10x your budget spend rate) pages a human immediately. A slow-burn alert with a 24-hour lookback and a low threshold (around 2x) opens a ticket for a problem that is quietly eating your month. That pairing is the whole point of burn-rate alerting on SLOs: page for the fire, file for the smoulder, and stop paging on single bad datapoints.

This article is about how to wire that up concretely on Google Cloud Monitoring and Amazon CloudWatch Application Signals, what to verify before you change any alert, and the cost you sign up for later when you tune the windows.

What burn rate actually measures

Burn rate is a multiplier on how fast you are consuming your error budget. A burn rate of 1 means you are spending budget at exactly the pace that exhausts it precisely at the end of the compliance window. A burn rate of 10 means you will exhaust the whole window's budget in one tenth of the window if the rate holds.

CloudWatch states the arithmetic plainly: <cite index="0-6">burn rate = error rate over the look-back window / (100% - attainment goal)</cite>. So for a 99.9% target, the denominator is 0.1%. If your measured error rate over the lookback is 1%, your burn rate is 10. The <cite index="0-5">look-back window is the time duration over which to measure the error rate</cite>, and choosing it is the single most consequential decision you make.

The error rate itself depends on SLO type. <cite index="0-8,0-9">For period-based SLOs, error rate is calculated as bad periods divided by total periods, where total periods represents the entirety of periods during the look-back window. For request-based SLOs, this is bad requests divided by total requests over the look-back window.</cite> Request-based SLOs behave more forgivingly because a later flood of good requests dilutes an earlier spike.

Why not just alert on the error rate

A raw threshold alarm fires on a single bad minute. Burn rate over a window smooths that out and ties the alert to actual budget consequence. The Amazon Product Search team put the failure mode of raw thresholds bluntly: <cite index="4-2,4-3">imagine your service experiences a brief spike in error rate, just a single datapoint; with threshold-based monitoring you will get notified immediately when that datapoint crosses your threshold, however since the error rate returns to normal right after, this alarm might not be worth your attention at 3am.</cite> Cranking up the datapoints-to-alarm count trades that false positive for slower detection of real incidents. Burn-rate windows resolve the tension instead of moving it around.

Check these before you touch alerting

Do not start editing alert policies. Start with the inputs those policies depend on.

• A defined SLI and target. You cannot compute a burn rate without an attainment goal in the denominator. If the SLO is still "we think it's about three nines", stop and pin it down first.
• The compliance window. On Google Cloud the lookback period doubles as the compliance period: <cite index="1-4">the lookback period determines how far back in time to retrieve data, and critically it is also used as the compliance period for calculating the SLO performance and error budget.</cite> Get that straight before you reason about thresholds.
• Traffic shape. Low-traffic services generate unstable error rates over short windows. <cite index="1-5,1-6">Shorter compliance periods provide faster detection but large changes in traffic and error rates over the course of a day may result in overly-sensitive alerting during low-traffic periods; consider using a burn-rate threshold significantly larger than 1 to reduce alert sensitivity during these times.</cite>
• Notification channels exist. A policy with no channel is a silent policy.
• On AWS, the service-linked role and SLO interval length. <cite index="0-14">The first time you create an SLO in your account, CloudWatch automatically creates the AWSServiceRoleForCloudWatchApplicationSignals service-linked role if it does not already exist.</cite> Also note the minimum interval, covered below.

If you are standing this up on a freshly migrated workload, you will not have a stable 30-day baseline yet, so treat your first thresholds as provisional and expect to retune once real production traffic settles. Getting SLOs and burn-rate alerts in place as part of the cutover, rather than months later, is exactly the kind of work our reliability and SRE engagements and our cloud migration service are built around.

Fast-burn and slow-burn: the two policies you need

Google's guidance gives concrete starting points. For the urgent case: <cite index="1-11">a good starting point for a fast-burn threshold policy is 10x the baseline with a short, 1- or 2-hour, lookback period.</cite> For the creeping case: <cite index="1-14">a good starting point for a slow-burn threshold is 2x the baseline with a 24-hour lookback period.</cite>

The reasoning behind each window is worth internalising so you can adapt it. <cite index="1-9">For a fast-burn alert, use a shorter lookback period so you are notified quickly if a potentially disastrous condition has emerged and persisted, even briefly.</cite> Conversely, <cite index="1-12,1-13">for a slow-burn alert use a longer lookback period to smooth out variations in shorter-term consumption, because a policy based on a shorter lookback with a high threshold might generate too many alerts even if the longer-term consumption levels out.</cite>

Route them differently. The fast-burn policy should page. The slow-burn policy should not wake anyone; it should create a work item to be triaged in hours, because "we are slightly ahead of where we want to be this month" is not a 3am problem.

Configuring it on Google Cloud Monitoring

Cloud Monitoring exposes burn rate through the select_slo_burn_rate time-series selector, where the second argument is the lookback. A fast-burn policy over a one-hour window looks like this via the Monitoring API:

{
  "displayName": "SLO fast-burn: 10x over 60m",
  "combiner": "AND",
  "conditions": [
    {
      "displayName": "Burn rate exceeds 10x baseline",
      "conditionThreshold": {
        "filter": "select_slo_burn_rate(\"projects/PROJECT/services/SERVICE_ID/serviceLevelObjectives/SLO_ID\", \"60m\")",
        "comparison": "COMPARISON_GT",
        "thresholdValue": 10,
        "duration": { "seconds": "0" }
      }
    }
  ],
  "notificationChannels": ["NOTIFICATION_CHANNEL"],
  "documentation": {
    "content": "SLO burn over the past 60m exceeded 10x the acceptable rate. Page on-call.",
    "mime_type": "text/markdown"
  }
}

POST it to https://monitoring.googleapis.com/v3/projects/PROJECT_ID/alertPolicies. The structure mirrors Google's own example, which uses select_slo_burn_rate(...) as the condition filter with a COMPARISON_GT comparison and a numeric thresholdValue, and it notes that <cite index="2-2,2-3">the combiner describes the logic for combining conditions, and with only one condition either AND or OR works.</cite> Duplicate the policy with the lookback set to "1440m" and the threshold to 2 for the slow-burn companion, and point it at a ticketing channel instead of a paging one. Fill the documentation field properly: it is <cite index="2-4">information sent when the condition is violated to help recipients diagnose the problem</cite>, and a runbook link there saves real minutes.

Configuring it on AWS CloudWatch Application Signals

Application Signals added burn rate for SLOs in late 2024. The feature lets you <cite index="3-2,3-4">calculate how quickly your service is consuming its error budget relative to the SLO's attainment goal, and configure CloudWatch alarms to notify you automatically when error budget consumption exceeds specified thresholds.</cite> You create one burn-rate metric per lookback window and alarm on it.

The multi-window pattern is assembled from CloudWatch primitives. Application Signals recommends starting with <cite index="0-12,0-13">a pair of burn rate alarms where one alarm has a look-back window that is 1/12th of the look-back window of the other, then setting a composite alarm on this pair.</cite> The composite alarm is what fires only when both the short and long windows agree, which is the mechanism that suppresses single-spike noise. The Amazon Search write-up confirms the approach directly: <cite index="4-8">you can aggregate a long window alarm and a short window alarm into one alarm with a CloudWatch composite alarm.</cite>

One hard constraint to plan around: <cite index="0-11">the previous strategy is possible only for SLOs with an interval length of at least three hours; for SLOs with shorter interval lengths, CloudWatch recommends you start with the 1/12th pair and a composite alarm.</cite> If your SLO interval is short, factor that in before designing windows. Also set both dimensions of reliability, not just uptime: CloudWatch recommends you <cite index="0-15">set both latency and availability SLOs on your critical applications</cite>, and you can attach an SLO to any metric or metric-math expression that resolves to a single time series.

Application Signals can suggest starting values from history. It <cite index="0-1,0-2">recommends SLO configuration parameters based on your service's historical performance, including a metric threshold calculated from actual performance over the last 30 days and recommended burn rate look-back window durations.</cite> Treat those as a starting point, not gospel, especially on a workload that has not accumulated 30 representative days.

The trade-off, and what it costs you later

Every burn-rate configuration is a bet on the shape of your traffic, and the bet has a bill.

Shorter windows detect faster and cost you noise. On a low-traffic service, a one-hour window can swing wildly on a handful of requests, and a fast-burn alert will page for statistical noise rather than a real regression. The fix is a higher threshold or a longer window, both of which slow your detection. There is no window that is fast and quiet on a service with little traffic; you pick which one hurts less and you document why.

Longer windows are calm and slow. A 24-hour slow-burn alert will genuinely miss a sharp outage that starts and is resolved inside an hour. That is acceptable only because the fast-burn alert is supposed to catch exactly that. If you delete the fast-burn policy to reduce paging, you have quietly removed your fast detection. Keep the pair intact.

Alarms are not free. The composite-alarm pattern multiplies alarm count per SLO. Multiply that across dozens of services and the line item is real. Budget for it rather than discovering it.

Availability is regional. Burn-rate support in Application Signals is not everywhere, so confirm your region before you design around it.

The version that ages badly is the one-alert setup: a single mid-range threshold that pages too often to be trusted and too rarely to catch slow burns. Building the two-policy pattern, wiring the routing, and encoding the runbooks is the sort of paved-road platform work our platform and DevOps engineering team standardises so every service ships with sane alerting instead of each team reinventing it.

Frequently asked questions

What lookback windows should I use for burn-rate alerts?

Start with the documented defaults and adapt. Google recommends roughly a 1 to 2 hour lookback with a 10x threshold for fast-burn paging and a 24-hour lookback with a 2x threshold for slow-burn tickets. On low-traffic services, lengthen the window or raise the threshold to cut noise, accepting slower detection as the cost.

What is the difference between a fast-burn and slow-burn alert?

Fast-burn uses a short window and a high threshold to catch a sudden outage that would exhaust your budget in days, and it pages a human. Slow-burn uses a long window and a low threshold to catch chronic low-grade errors that quietly consume the month, and it should open a ticket rather than page. You need both because each covers the failure mode the other misses.

How is burn rate calculated?

Burn rate equals the error rate measured over the lookback window divided by one minus the attainment goal. For a 99.9% target with a 1% observed error rate over the window, the burn rate is 10, meaning you would exhaust the window's budget in one tenth of the window at that pace. Period-based and request-based SLOs count the error rate differently, so decide the SLO type first.

Can I do multi-window burn-rate alerting in CloudWatch?

Yes. Create two burn-rate alarms where the short window is one twelfth of the long window, then combine them with a CloudWatch composite alarm so the alert fires only when both agree. <cite index="0-11">For SLOs with shorter interval lengths, CloudWatch recommends you start with the 1/12th pair and a composite alarm.</cite>

Why not just alert when the error rate crosses a threshold?

A raw error-rate threshold fires on a single bad datapoint that may resolve immediately, producing pages that are not worth acting on at 3am. Raising the datapoints-to-alarm count reduces those false positives but delays detection of real incidents. Burn-rate windows tie the alert to actual error-budget consequence, catching sustained problems while ignoring transient spikes.