A duration clause such as "fire only if the condition holds for one hour" treats every incident the same. A total outage waits as long as a small leak, and one brief recovery resets the clock, so flapping failures may never alert. Use a burn rate approach with two windows instead.
What the clause does
Many alerting tools let you write a condition plus a duration. The goal is sensible: avoid paging on a spike that clears in seconds. The cost is less obvious.
Problem one: severity is ignored
The SRE workbook points out that a duration clause does not scale with severity. A complete outage and a 0.2 percent error rate wait the same hour before anyone hears about it. With a 99.9 percent SLO over 30 days, a total outage uses more than the whole month's budget in that hour. Waiting that long is a poor trade.
Problem two: recovery resets the timer
If the condition drops below the threshold for even a moment, the countdown starts again. A service that fails for 50 minutes, recovers for one, fails for 50 more and repeats may never alert at all, even though users have a bad time throughout.
Problem three: you pick between fast and quiet
Shorter windows detect quickly but fire on small events. The workbook's example is that a 0.1 percent error rate over 10 minutes uses only about 0.02 percent of a monthly budget and still alerts. Longer windows are quieter but keep firing for hours after the system has recovered.
What to do instead
Use burn rate alerts with a long and a short window, and require both. Choose thresholds so a fast, severe problem pages within minutes, and a slow leak creates a ticket. The workbook's starting table for a 99.9 percent SLO uses a one hour and five minute pair at 14.4 for pages, and a three day and six hour pair at 1 for tickets.
If you cannot adopt that yet, a cheap improvement is to alert on the ratio over a few windows at once, such as 5 minutes and 1 hour, and send each to a different channel.
When a duration clause is fine
It is a reasonable guard for signals that are noisy by nature, such as a single probe from one location. Keep the duration short, a few minutes, and combine it with a second check from another location.
A review you can run this week
Search your alert rules for duration clauses over 15 minutes. For each, ask what the worst case is if the condition flaps, and whether a user would notice before the alert fires. Rewrite the ones that fail that test first.
Quick check
Is a short duration clause always wrong?
No. A few minutes of delay can filter transient spikes. The problem is long clauses on high impact conditions.
Does burn rate alerting need a mature SLO program?
You need an agreed target and a trustworthy error ratio. You do not need a full program to start.
Sources
Related: SLO burn rate alerts explained.
Last reviewed: 19 October 2026.
