Your error budget burn alert pages every few hours, but half the time nobody outside the team has noticed anything. How do you tune it without simply making it quieter?

Short answer

A single burn-rate threshold over a single window has to choose between catching fast outages and ignoring brief spikes, and it cannot do both. The standard fix is multi-window, multi-burn-rate alerting: a fast rule that pages a human and a slow rule that files a ticket, each paired with a short window so an incident that has already recovered stops alerting. Before touching thresholds, though, check the SLI — most spurious pages are a measurement problem wearing an alerting costume.

What burn rate actually means

The error budget is the failure you have deliberately allowed: at a 99.9% availability SLO over thirty days, 0.1% of requests may fail. Burn rate expresses how fast you are spending it relative to spending it evenly. A burn rate of 1 consumes the budget exactly over the window, exhausting it precisely at day thirty. A burn rate of 14.4 consumes it fourteen times faster, which means 2% of a thirty-day budget disappears in one hour.

Stating it that way matters, because it explains the numbers that otherwise look arbitrary. 14.4 is not a magic constant; it is what "2% of a 30-day budget in 1 hour" works out to. Being able to derive it rather than recite it is usually what an interviewer is checking.

Why one window cannot work

Set the window short — say five minutes — and you are alerting on a tiny sample. At 3am, forty requests an hour means roughly three requests in five minutes; one failure is a 33% error rate and the pager goes off for a single blip that no user noticed. That is the noise the question describes.

Set the window long — say six hours — and the alert is trustworthy but late. A total outage burns the entire monthly budget in around 43 minutes at 99.9%, so a six-hour window notices well after the damage is complete.

Neither window is wrong. The mistake is expecting one of them to do both jobs.

The rules to actually deploy

Two alerts, each with a long window that decides significance and a short window that decides whether it is still happening:

# Page: fast burn. 2% of a 30-day budget consumed in 1 hour.
- alert: ErrorBudgetFastBurn
  expr: |
    burn_rate_1h  > 14.4
    and
    burn_rate_5m  > 14.4        # short window: stops paging once it recovers
  severity: page

# Ticket: slow burn. 5% of the budget consumed in 6 hours.
- alert: ErrorBudgetSlowBurn
  expr: |
    burn_rate_6h  > 6
    and
    burn_rate_30m > 6
  severity: ticket

The short window is the part that fixes the specific complaint in the question. Without it, a five-minute spike at 09:00 keeps the one-hour rule above threshold until 10:00 — so you get paged at 09:05 for something already over, and paged again if you silence and re-arm. Requiring the short window to also be burning means the alert clears as soon as the incident does.

Adding a third, slower rule — burn rate 1 over three days — as a ticket rather than a page catches the chronic low-level burn that never trips either fast rule but still exhausts the budget by day twenty-five.

Check the SLI before you touch the thresholds

Half of "the alert fires but nobody complains" is not the alert. It is that the SLI measures something other than user experience. The usual culprits:

The denominator includes traffic that is not users. Health checks, uptime probes, and crawler traffic inflate request counts and, when they fail during a deploy, produce errors no human experienced. Kubernetes liveness probes failing during a rolling restart is a classic source of a page nobody can explain afterwards.

The numerator counts the wrong failures. A 404 for a URL a user mistyped is not your service failing. A 401 on an expired token is the system working. Counting all non-2xx as errors makes the SLI track user behaviour rather than service health. So does counting each retry of a request the client eventually succeeded on — the user saw success, your SLI recorded three failures.

It is measured in the wrong place. Errors counted at the application miss the ones the load balancer returned when the pod was unreachable, which are exactly the ones users notice most.

It is not a journey. A single service-wide availability number averages the checkout path together with a rarely used settings page. Ten minutes of broken checkout barely moves it; a broken settings endpoint pages at 3am. Splitting SLOs by critical user journey fixes more false pages than any threshold change.

Low traffic needs a floor, not a threshold

Burn rate is a ratio, and ratios are unstable when the denominator is small. The fix is not a different threshold but a minimum volume gate: require some absolute number of failed requests — say five in the window — before the rule can fire at all. Below that, the honest position is that you have insufficient data to say the SLO is being missed, and paging on it is guessing. For genuinely low-traffic services, either widen the windows so the sample is meaningful or accept that availability alerting is the wrong instrument and alert on something deterministic like process health instead.

The fix to refuse

The tempting response to a noisy pager is to raise the threshold until it stops. That does not tune the alert; it deletes the signal while keeping the dashboard that implies you have one. If the burn is real and you raise the threshold above it, you have chosen not to be told about a genuine outage, and you will discover that during the next one.

The legitimate version of "make it quieter" is to move an alert from page to ticket. A slow burn is real and worth acting on, and it does not need someone woken up. Most over-paging teams have a severity problem rather than a threshold problem.

Closing the loop with a policy

An alert is only meaningful if exhausting the budget changes something. The error budget policy is the agreement made in advance — typically that when the budget is spent, feature releases pause and reliability work takes priority until it recovers. Without it, the burn alert is a number that fires and is acknowledged, teams learn it has no consequences, and the pager fatigue in the question returns for a different reason. Mentioning the policy unprompted is a strong signal, because it shows the candidate understands SLOs as a decision-making tool rather than a monitoring feature.

---

© 2026 Preptima. Originally published at preptima.com.