How to cut RMM alert noise without missing the one that matters
Every RMM ships with defaults designed to be safe for everyone, which means they are wrong for you. The result is familiar: thousands of alerts a month, a team that has learned to ignore the queue, and an incident that sat unread for six hours because it looked like the other four hundred.
Alert tuning is unglamorous and it is the highest-leverage work in a NOC. Here is a method that works regardless of which platform you run.
Start by counting, not by tuning
Before changing a threshold, pull 30 days of alert history and group it. You want three numbers per monitor:
- Volume — how many fired
- Actionability — how many led to a change of any kind
- Client spread — one client or many
A monitor with high volume and near-zero actionability is noise. A monitor with high volume concentrated in one client is usually an environment problem, not a monitoring problem — fix the environment.
Most estates find that 10–15 monitors generate the large majority of volume. That is where you work. Ignore the long tail at first.
The four moves
For each noisy monitor there are only four things you can do.
Raise the threshold. The blunt instrument. Appropriate when the default is simply wrong for the workload — disk at 80% on a server that has run at 84% for three years.
Add duration. Far better than raising thresholds and consistently underused. Most transient spikes are meaningless. "CPU above 90% for 15 minutes" removes enormous volume while keeping every real event.
Scope it. The same threshold rarely suits a terminal server and a batch server. Split the monitor by role. This is more work up front and it is the move that produces the durable reduction.
Suppress on a schedule. Backup windows, patch windows, known batch jobs. Suppression is safe when it is tied to a window and dangerous when it is permanent.
What to never suppress
Some alerts should stay noisy no matter how annoying they are, because the cost of missing one is unbounded:
- Backup job failures — including "completed with warnings"
- RAID or storage degradation
- Domain controller replication failures
- Certificate expiry inside 30 days
- AV or EDR disabled on any endpoint
- Any monitor that has fired for a genuine P1 in the last 12 months
If you find one of these in your suppression list, someone was solving for a quiet queue rather than a working estate.
Measuring whether tuning worked
The tempting metric is total alert count, and on its own it is misleading — you can always get to zero by turning everything off.
Track these together:
- Alert volume — should fall
- Actionability rate — the share of alerts leading to a change; should rise
- Escalations — should fall
- Incidents found by clients rather than monitors — must not rise
That last one is the control. If client-reported incidents are climbing while your alert volume falls, you have tuned past the signal. Nothing else in the set will tell you that.
Platform notes
The mechanics differ but the method does not.
- ConnectWise Automate — internal monitor sets are per-group; build role-based groups first or you will be editing the same monitor repeatedly.
- NinjaOne — policy inheritance is the lever. Tune at the policy level, override per device only as an exception, and audit the overrides quarterly.
- Datto RMM — monitors live in component-level policies; duration windows are the single highest-return setting.
- Kaseya VSA — the counter thresholds are granular; the risk is fragmentation, so keep a documented standard.
How long this takes
For a typical MSP estate, the first pass takes two to four weeks of part-time attention and removes a large share of volume. The long tail is a quarterly habit, not a project.
The mistake is treating it as a one-time cleanup. Estates change, clients get onboarded, and noise accumulates. Tuning is maintenance.
Alert tuning is part of onboarding at NOC247 — we do not simply forward your existing feed. See how coverage works.