Cross-posted from the Fluidify blog.
Every few years, a team gets tired of drowning in pages and migrates to a new on-call tool. The rollout goes fine. Schedules import cleanly, integrations reconnect, everyone gets a shiny new mobile app. Then, somewhere between four and twelve weeks later, the same on-call engineer who pushed for the migration is back to muting notifications at 2 a.m. and triaging the same noisy alert they were triaging on the old platform.
This isn't a failure of the new tool. It's what happens when a team changes where the alerts land without changing what causes them to fire in the first place. The rules that produced fatigue on the old system, which alerts get created, how they escalate, who they wake up, come across in the migration as faithfully as the schedules do. A new UI on top of the same rules produces the same outcome with a different logo.
What actually causes alert fatigue
Three root causes show up in almost every team that reports fatigue, regardless of which tool they're on:
Noisy sources with no classification layer. Most alerting pipelines treat every signal from Prometheus, CloudWatch, or a health check as equally worth a human's attention. A flapping check that recovers in ninety seconds pages the same way a full outage does. Without deduplication and severity classification at the point alerts are generated, the on-call engineer becomes the classification layer, by hand, every single time.
Escalation policies that don't differentiate urgency. A five-minute escalation timeout makes sense for a payment outage. It does not make sense for a disk-usage warning that can wait until morning. When every alert type shares one escalation policy, either the urgent stuff waits too long or the routine stuff interrupts sleep, and teams routinely get this backwards in both directions on the same policy.
No owner for alert hygiene. Someone has to look at the alerts that fired last week, decide which ones were useful, and either fix, downgrade, or delete the ones that weren't. In most teams, nobody owns this. It falls to whoever happens to be on-call when they get frustrated enough, which means the noisy alert survives until someone has a bad week and finally kills it out of spite. That's not a process, and it doesn't scale.
Why a new tool doesn't fix any of the three
None of those three causes live in the vendor. Classification, escalation policy design, and hygiene ownership are decisions a team makes and re-makes, and a tool migration is exactly the moment those decisions get carried over unexamined, because reproducing the existing setup quickly is the whole point of a smooth migration. The team optimizes for "nothing broke" and, in doing so, optimizes for "nothing changed," including the parts that were broken.
The tools also look similar enough on this specific axis that switching between them rarely forces the issue. Every mainstream on-call platform supports severity levels, deduplication rules, and tiered escalation. The gap isn't feature availability. It's that configuring those features well takes an audit most teams skip during a migration.
If a migration is already on the table, it's worth doing the audit below before comparing vendors, not after.
What actually works
The interventions that measurably reduce fatigue touch the three root causes directly, independent of vendor:
Classify and deduplicate at the source, not at the human. Group alerts from the same root cause into one notification. Suppress known-flapping checks instead of paging on every transition. This is configuration work on the monitoring side (Alertmanager routing rules, Grafana notification policies) as much as the on-call tool.
Match escalation speed to actual urgency, per alert type, not per team. A payment-path outage and a disk-warning should never share an escalation policy. Once that logic is right, managing it as version-controlled config instead of a vendor UI setting is what keeps it from drifting back.
Name an owner for alert hygiene, and give them a recurring slot. Someone reviews the last week or month of pages, tags what was noise, and has the authority to retune or delete rules without three approvals.
Close the loop after every incident. If a postmortem doesn't produce a concrete change to an alert rule or escalation policy when the alert was part of the problem, the same failure mode reappears with the label "known issue" attached to it.
A 30-day exercise that costs nothing
Before any team migrates on-call tools to solve fatigue, it's worth running this against the current one:
- Pull every page from the last 30 days, grouped by alert rule.
- For each rule, tag it: actionable, informational (nice to know, didn't need a wake-up), or noise (should never have paged).
- For anything tagged noise, delete the rule, add deduplication, or move it off the paging path entirely.
- For anything tagged informational, move it to a lower urgency tier with a slower escalation.
- For actionable pages, check that the escalation timeout matches how much time the team actually has before impact grows.
Most teams find that a third to half of their pages fall into noise or informational once they actually look, on the tool they already have. If fatigue is still there after that exercise, a new tool might genuinely help.
FAQ
Does a better on-call tool ever fix alert fatigue? It can remove friction around fixing it, but the tool doesn't do the classification or ownership work for you.
How do we know if our escalation policies are the problem? Check how many pages resolved themselves or were ignored until auto-resolve, versus how many required real action within the escalation window. A high self-resolving ratio usually means the timeout is too aggressive.
Who should own alert hygiene without a dedicated SRE team? Rotate it with the on-call schedule: whoever was on-call last week reviews last week's pages before handing off.
I build FluidifyAI Regen, an open-source on-call and incident tool, and this exact pattern is why its AI-generated post-mortems flag the specific alert rules involved in an incident rather than just summarizing what happened. A tool can make the hygiene work faster to do. It can't do the work of deciding what deserves a human's sleep for you.
