RMM alert fatigue: what to silence

An RMM that pages you for every transient CPU spike is not monitoring — it is a denial-of-service attack on your technicians. Alert fatigue is not a discipline problem; it is a configuration problem. When everything is critical, nothing is.

The goal is not zero alerts. The goal is alerts that imply action within a defined window — and silence on everything else until you have evidence it matters.

Noise you should almost always tune down

Ephemeral resource warnings. CPU at 95% for two minutes during Windows Update is not an incident. Disk at 85% on a volume that grows predictably every month needs a ticket on a schedule, not a 3 a.m. page.

Patch “failed” on laptops that were asleep. Retry windows exist for a reason. Alert when failure persists across multiple cycles, not on the first attempt while the device was in a bag.

Service stopped — once. Many services restart themselves. Alert on sustained down state or repeated restart loops, not a single blip during reboot.

AV “definitions old” on offline machines. Traveling laptops will always lag. Escalate when a device has been online for 72 hours and still has stale defs — not the moment it checks in from a hotel.

Informational script output. If your monitor returns text every hour, it is a log file, not an alert. Route to reporting; do not open tickets.

Signals you should not silence

Be careful here. These are the alerts people mute right before something bad happens:

• Backup job failed (two consecutive failures, or one failure on a system with no secondary backup)
• Disk below free-space threshold on production volumes — especially databases and mail stores
• Repeated failed logons to admin accounts or RDP gateways
• Security agent offline on servers (not “user disabled tamper protection because installer asked” — that one needs a human, fast)
• Certificate expiry inside 14 days on anything public-facing
• Unexpected new local admin or security software tampering

If you silence these to “reduce noise,” you are not reducing noise — you are reducing visibility.

A sane severity model for SMB shops

Use three tiers and mean them:

• P1 — Act now: Production down, active security control failure on a server, backup chain broken with no fallback
• P2 — Same business day: Degraded but working, repeated failures trending wrong, expiring cert inside a week
• P3 — Scheduled: Capacity planning, patch retries, informational drift

Every monitor should map to a tier. If you cannot name the action for an alert, delete the monitor or demote it to a weekly report.

Maintenance windows and ownership

Silence alerts during planned change windows — patch Tuesday, firewall firmware, ISP maintenance — with calendar entries tied to RMM maintenance mode. Unplanned silence (“we were busy”) is how missed outages happen.

Assign monitor owners. One technician owns backup alerts, another owns server health. Orphan monitors creep back to defaults after vendor updates.

Review quarterly with ticket data

Pull ninety days of tickets tagged “monitor” or auto-generated from RMM. Sort by volume. The top five noisy monitors are your homework list. For each, ask: Did any of these tickets prevent data loss or downtime? If no, tune or kill.

Bottom line

RMM alert fatigue is fixed by aggressive tuning of ephemeral noise, a honest three-tier severity model, and quarterly review against actual incidents — not by training technicians to ignore their phones. Keep backup failures, admin abuse signals, and security agent health loud; turn down everything that is really a log entry wearing a siren costume.