Four hundred alerts.
None of them useful.
Every network team has a channel nobody reads. It filled up honestly — one reasonable threshold at a time — and now it is the most expensive thing on the network.
Alert fatigue is what happens when a monitoring system's output stops being worth reading, and it is caused by fixed thresholds rather than by too much monitoring. A threshold is a number somebody chose once, on a network that has since changed. It fires on legitimate variation, stays silent through slow degradation that never crosses it, and cannot distinguish a cause from its twenty downstream effects. The fix is not fewer alerts but different ones: a baseline learned from your own traffic, and correlation that reports one incident instead of twenty symptoms.
Five causes of an unreadable alert channel.
A number chosen for a network that no longer exists
The threshold made sense when it was set. Since then you have added sites, moved workloads and changed backup windows. It now fires on Monday mornings because Monday mornings are busy.
A giveaway: alerts that recur on a weekly or monthly rhythm. That is a business pattern, not a fault.
One event reported twenty times
A link drops and every device behind it reports unreachable. All twenty alerts are accurate; nineteen of them are noise, and the one that matters is somewhere in the middle.
Correlation should collapse these into one incident with a cause and a blast radius.
Alerts nobody can act on
If the only response is to acknowledge it, it is not an alert — it is a metric that should be on a dashboard. Every one of these trains the team to skim.
Test: for each alert type, what did the recipient actually do last time? If the answer is nothing, it should not page anyone.
The problems that never cross a limit
A retransmission rate climbing from 0.2% to 1.4% over two days. A server response time tripling. Neither trips a threshold, and both are what users are feeling.
This is the expensive half. The channel is loud and the real problem is not in it.
Severity that means nothing
When most things are critical, nothing is. Severity drifts upwards because raising it is how you get a thing looked at, and the scale stops carrying information.
If more than a small fraction of alerts are critical, the scale has collapsed.
Four steps to a channel worth reading.
- 1
Count what you actually acted on
Take a month of alerts and mark the ones that produced an action. The ratio is usually startling, and it is the number that justifies changing anything.
- 2
Silence the ones with no action, permanently
Not snoozed — moved to a dashboard or deleted. Every unactioned alert costs attention that the real ones need.
- 3
Collapse the effects into their cause
Group by topology, so a failed uplink reports as one incident with everything behind it listed, rather than as twenty independent failures.
- 4
Replace fixed limits with a learned baseline
A baseline adapts to legitimate change and flags departures from your own normal, which removes the recurring false positives and catches the drift that thresholds cannot see.
The alert that never fires.
Drag the timeline. The threshold is never crossed at any point in the incident, so a threshold-based system stays silent throughout — while a learned baseline has already flagged the drift.
Net-Monitor has learned what this part of your network normally does at this time of day. Traffic is comfortable, the wire is clean, and nobody needs to be told anything.
- Link utilisation
- 39%
- Response time
- 24ms
- Sniffer packet errors
- 0.2%
- Risk score
- 2/100
Utilisation is comfortable and the wire is clean.
What changes with a learned baseline
- Normal is measured, not declared. The baseline comes from your own traffic and keeps adapting, so a busy Monday stops being an incident.
- Detection runs on the packets, online. Working from the traffic rather than five-minute averages is what makes it possible to name a cause instead of raising a flag.
- Fewer alerts, and different ones. The goal is a channel where every entry is worth reading — which means removing noise and adding the things thresholds structurally cannot catch.
Short answers.
How do I reduce false positive network alerts?
Start by measuring which alerts led to an action over the last month, and remove the rest outright rather than snoozing them. Then collapse related alerts into a single incident using topology, so one failure reports once. Finally, replace fixed thresholds with a baseline learned from your own traffic, which removes the recurring false positives caused by legitimate variation.
What is the difference between a threshold and a baseline?
A threshold is a fixed number chosen in advance — it fires when a metric crosses it, regardless of whether that is normal for your network at that hour. A baseline is learned from observed behaviour and flags departures from it, so it adapts as the network changes and can catch a gradual drift that never crosses any particular limit.
Does anomaly detection generate more alerts or fewer?
Fewer, when it is working properly. It removes the recurring false positives that fixed thresholds produce on legitimate patterns, and it adds a smaller number of genuinely unusual events. The volume goes down and the signal goes up; if the volume goes up, the baseline has not learned enough yet.
How long before a baseline is useful?
It needs to observe enough of your normal cycle to know what normal looks like — including the weekly rhythm, since Monday and Sunday are different networks. It keeps refining after that, and it re-learns when the network genuinely changes rather than treating the change as a permanent fault.
Related questions.
How many of last month's alerts did anyone act on?
It is worth counting before a demo. The answer usually makes the rest of the conversation short.