An alert system that cries fifty times a day will be muted within a week - and then it protects nothing. Good alerting is not about catching everything. It is about making every single alert worth reading.
Every monitoring tool can send alerts. Very few setups send useful ones. The difference is discipline: two severity levels, a delay before firing, different rules for office hours and night, and the courage to delete alerts that never lead to action. This page is the practical method, using the threshold and alarm features you get in tools like ManageEngine Applications Manager.
Severity decides the channel. A warning never deserves the same noise as a dead server.
Every condition gets exactly two thresholds:
If a warning and a critical arrive through the same loud channel, you will treat both as noise. The channel itself is the priority signal.
Servers spike. A backup starts, an antivirus scan runs, fifty users log in at 9 AM. A threshold crossed for one polling cycle is weather, not climate.
This one rule removes most false alarms without hiding a single real incident - real problems stay broken; spikes do not.
Before saving any alert, ask one question: "If this fires at 3 AM, will I get up and do something?"
Most setups fail this test badly: disk warnings, certificate expiry reminders and backup reports all screaming like a dead server. Downgrade everything that fails the test and your night alerts become trustworthy again.
Patch Tuesday restarts, nightly backups and month-end reports all create predictable "problems". Use maintenance or downtime schedules for those windows so the tool stays quiet during planned work - and keeps its credibility for unplanned work. An alert that fires during every backup teaches the whole team to ignore alerts during backups, which is exactly when a real disk failure chooses to appear.
Once a month, look at the alert history and ask of each repeating alert: did anyone act on it? An alert that fired twenty times with zero action is not monitoring - it is litter. Fix the underlying condition, fix the threshold, or delete the alert. A quiet console with twelve meaningful alerts protects you better than a loud one with two hundred.
See the full live demo - adding servers, reading the dashboard and setting alerts, step by step.
▶️ Watch Full VideoUsually one failed poll caused by a busy network or a momentarily overloaded server. Require 2–3 consecutive failed checks before the down alert fires, and most of these ghosts disappear.
As a starting point, yes - warning near 80% and critical near 90% works for many office servers. But watch the fill rate: a disk that gains 5% a day needs earlier warnings than one that has sat at 82% for a year.
There is no magic number, but the test is behavioural: if your team has started ignoring or muting alerts, you have too many, whatever the count says.