The alert board at nine in the morning
Overnight, the RMM created a few hundred tickets. A print spooler restarted itself on dozens of PCs. Several laptops went offline because their owners went home. A server's disk crossed eighty per cent, as it does every night during the backup, then fell back. One alert, buried in the middle, says a client's firewall stopped responding at three in the morning and never came back.
The engineer on the alert queue starts closing tickets in bulk, as always. The firewall ticket is closed with the rest, because it looks like the laptop offline alerts. At half past nine, the client phones to say nobody can get online.
Why alert noise builds up
Monitoring policies are usually applied from templates at onboarding, with thresholds chosen to be safe. Nobody has time to tune them per client, and every new monitor added after an incident adds more noise.
- Thresholds are the template defaults, not suited to each device.
- Self-resolving alerts create tickets that close themselves, training engineers to ignore alerts.
- Workstations and servers are monitored with similar urgency.
- Repeat alerts on the same device create separate tickets.
- Nobody reviews which monitors are useful and which are just noise.
New clients make it worse each time. The standard policy goes on at onboarding, before anyone knows what normal looks like for that client's devices, and the backup server that fills its disk every night or the laptop that sleeps all weekend starts generating alerts from day one.
What the noise costs
| Noise effect | Consequence |
|---|---|
| Real alerts lost among routine ones | Outages noticed by clients first |
| Bulk closing becomes habit | Engineers stop reading alerts properly |
| Ticket volume inflated | Client effort figures and reports distorted |
| Engineer time on triage | Hours a week spent closing tickets |
| Monitors never tuned | The problem grows with every new client |
The alert layer we build
- Alerts taken from your RMM (NinjaOne, Datto RMM, N-able or similar) before they become PSA tickets, through its API or webhook.
- Grouping of repeat alerts on the same device and condition into one ticket with a count, rather than many tickets.
- Suppression rules for alerts that resolve themselves within a time you set, agreed with your service manager and reviewed regularly, with every suppressed alert still logged.
- Ranking by device role (server, network device, workstation), client tier and business hours, so a firewall down at a top-tier client outranks a laptop offline.
- Enrichment of each ticket with recent history for that device, so the engineer sees whether it is a new problem or a repeat.
- A weekly noise report showing which monitors and which clients generate most alerts and how many needed action, as a tuning list for the RMM.
Suppression is always a rule you approve, never something the system decides on its own. The goal is fewer tickets for the same level of attention, not less monitoring.
A morning with less noise
The alert queue now shows a short list, ranked. The firewall alert sits at the top with a note that the device has not responded for six hours and has no history of doing this. The print spooler restarts are one grouped ticket per client with a count, marked as self-resolved. The overnight backup disk alerts are suppressed under an approved rule and logged.
Each week, the service manager looks at the noise report and picks two monitors to tune: the disk threshold on servers that hold backup staging, and the offline alert for laptops outside office hours. Over a few months, the RMM's own alert volume drops, and the service desk starts trusting alerts again.
Client reports get more meaningful too, because ticket counts reflect real work rather than monitoring chatter.
Is alert noise wearing down your desk?
- Engineers close RMM alert tickets in bulk every morning.
- A client has told you about an outage your monitoring caught but nobody saw.
- Most alert tickets close without any action.
- Monitoring thresholds are the template defaults.
- Nobody knows which monitors are useful.