An alarm storm is not a monitoring success — it is a monitoring failure wearing a costume. When every email is noise, the one real alert drowns with the rest.
The pattern is always the same. OpManager goes live, the defaults are enthusiastic, and within a week the IT inbox holds four hundred alarms a day: CPU crossed 90 percent for one poll, a laptop’s interface flapped, the same switch reported the same fault forty times. The team does the only rational thing — they stop reading. Then a genuinely critical device fails inside the noise and the post-mortem asks why the monitoring “didn’t warn us”, when it did, four hundred times, about everything. Alarm quality is a design problem, and it is solved with four levers OpManager already gives you: thresholds that require persistence, rearm values that end flapping, dependencies that collapse one root cause into one alarm, and downtime schedules that silence planned work. Pull them in that order.
Same network, same failure. Tuning decides whether the console informs you or shouts at you.
Most storms are manufactured by thresholds that fire on a single poll. A server’s CPU touching 92 percent during one backup is not an incident; it is Tuesday. For every performance monitor, set the rule as a breach sustained over consecutive polls — OpManager lets a threshold violation count only after it repeats — and pick the count from the device’s role: three to five consecutive breaches for servers, more for links that spike legitimately. Availability (device down) stays immediate; performance must prove it means it.
Flapping is the second storm factory: a value hovering at 89–91 percent against a 90 percent threshold raises, clears, raises, clears — an email each way. The cure is a gap: alarm at 90, clear (rearm) only below 80. OpManager’s threshold profiles support separate violation and rearm values precisely for this. Apply the same pattern to disk space and interface utilisation. Any monitor that has alarmed more than a few times in a week without a human acting is not a monitor — it is a noise generator, and it gets retuned or deleted at the weekly review.
When a distribution switch dies, everything behind it goes dark — and an untuned OpManager reports a massacre: thirty devices down. Teach it the topology. OpManager supports device dependencies: mark the downstream devices as dependent on that switch, and when the parent fails, the children’s alarms are suppressed and the parent carries the single critical alarm. The night’s record becomes one line that tells the truth — the switch is down, the rest is consequence. Build dependencies for the core switch, the firewall, and any single uplink each floor or branch hangs from.
Patching weekends, backup windows and ISP maintenance all produce real faults on a schedule — and every one of them trains the team to ignore alarms. OpManager’s downtime schedules suppress monitoring or alarms for chosen devices in chosen windows. Put the backup window in (the CPU alarm during the 1 a.m. job is not news), put the monthly maintenance slot in, and make adding a downtime entry part of the change process itself: no approved change, no silence. Suppression that is scheduled and visible is discipline; suppression by ignoring the inbox is decay.
Finally, route by severity honestly. Let warnings land on the dashboard only, troubles reach the IT group’s email, and criticals escalate — email plus SMS or a helpdesk ticket — with escalation to a second person if unacknowledged after a set time, a feature the Standard edition already includes. Then run the ten-minute weekly ritual: open the alarm history, sort by count, and interrogate the top five talkers. Each one gets fixed, retuned or consciously accepted — in writing, in the ticket, never by shrugging. Alarm volume is a metric; drive it down until the inbox is boring, because boring is what trustworthy looks like.
Thresholds and notification profiles are set in the same console the setup video tours — watch it, then tune with this page as the checklist.
▶️ Watch Full VideoThere is no magic number, but the pattern is clear: a healthy setup produces a handful on a normal day, and every one is actionable. If a single device produces most of your alarms, that device — or its threshold — is the problem to fix this week.
By minutes, yes — deliberately. A CPU fault that matters will still be there in three polls; one that vanishes was never an incident. Keep device-down availability alarms immediate, and let performance alarms prove persistence.
Suppression holds back alarms for devices affected by a known root cause, typically through dependencies. A downtime schedule silences a planned window in advance — maintenance, backups, ISP work. You need both: one for surprises, one for the calendar.