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:
- alert: ErrorBudgetFastBurn
expr: |
burn_rate_1h > 14.4
and
burn_rate_5m > 14.4 # short window: stops paging once it recovers
severity: page
- 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 (opens in a new tab).