A channel with two hundred alerts a day is not monitoring. It is a feed that has trained everyone to ignore it, and it carries the additional harm of appearing to be a safety net.
Alert fatigue is not a discipline problem. It is a design problem with a well-understood cause: alerting on conditions rather than on consequences.
Alert on symptoms, not causes
High CPU is not a problem; it may be a busy system working correctly. Users experiencing errors is a problem. Alert on what a customer would notice — error rates, latency, failed transactions — and use dashboards for the underlying causes once you are looking.
This single change usually removes the majority of noise.
Every alert needs an action
If the response to an alert is "note it and move on", it should not be an alert. Test each one by asking what the recipient is expected to do at three in the morning. Anything without a clear answer belongs on a dashboard or in a weekly report.
Route by ownership
Alerts sent to everyone are actioned by no one. Each should reach a specific team that can actually resolve it, with a documented escalation path when they cannot.
Review what fired
Once a month, look at what alerted and what came of it. Delete anything that fired repeatedly without a resulting fix, and tighten anything that produced a false alarm. Alert configuration decays exactly like code, and almost nobody maintains it.
Track the misses too
After each incident, ask whether an alert fired, and if not, why. That is the only feedback loop that improves coverage, as opposed to merely reducing noise.
A small number of trustworthy alerts beats comprehensive coverage that everyone has learned to dismiss.