It is 2:14 AM and a Hyper-V host at your second-largest client just stopped responding. Your RMM did its job: the monitor fired, the alert was born. Then it landed in a shared mailbox alongside forty-one other messages that arrived since midnight — disk warnings, a flapping VPN sensor, two backup notices, and a printer that has been "offline" since 2024. Nobody's phone made a sound. The client noticed the outage before you did.
This is the standard failure mode of MSP alert management. It is almost never a monitoring problem — Automate, Datto RMM, N-central and PRTG are all perfectly good at noticing that something broke. It is a routing and ownership problem: the alert reached a place instead of a person, and no process existed to make a specific human accountable for it within a specific number of minutes.
The five failure modes of MSP alerting
1. Alerts route to a place, not a person. A shared inbox, a #alerts channel, an email-to-ticket queue. During business hours someone probably picks it up. After hours, everyone assumes someone else saw it. A channel cannot be woken up.
2. Nothing escalates.One email is sent, once. If the on-call engineer is asleep, driving, or already heads-down on another issue, there is no step two. The alert's entire delivery strategy is hope.
3. Every alert has the same volume. When a down production host and a toner warning arrive through the same pipe with the same urgency, engineers learn to ignore the pipe. Alert fatigue is not caused by too many alerts — it is caused by too many alerts that didn't matter teaching people that none of them do.
4. Planned work pages people anyway.Patch night fires fifty "server rebooting" alerts, someone gets paged at 11 PM for maintenance they scheduled themselves, and next week they mute the channel entirely. The noise from expected work destroys trust in the unexpected alerts.
5. Alerts die at shift boundaries.An alert acknowledged at 4 PM is still being "monitored" when the engineer leaves at 5. The next engineer never hears about it. This is the same shift-boundary failure that loses tickets — except an unresolved alert is usually attached to something actively burning.
What good MSP alert management looks like
Route to the engineer on call — the schedule is the source of truth
The single highest-leverage change: alerts page whoever the on-call schedule says is responsible right now, not a distribution list. That requires your alerting layer and your on-call schedule to be the same system (or tightly integrated) — when the rotation changes, routing changes with it, automatically. No stale distribution lists, no "wait, is Jake still on-call this week?"
Escalate until a human acknowledges
A page that cannot escalate is a suggestion. A working escalation ladder looks like: step one pages the on-call engineer by SMS and push immediately; step two pages again plus Slack after five minutes; step three notifies the whole team after another ten. Acknowledging from anywhere — web, a Slack button, an SMS reply, an email link — stops the ladder instantly. The goal is not maximum noise; it is a guarantee that a critical alert cannot go unseen for more than a defined number of minutes.
Tier severities so P1 means something
Map alerts onto a small severity scale (P1–P4 works) and give each tier a different contract: P1 and P2 page immediately and escalate hard; P3 can wait thirty minutes or just land as email to the on-call engineer; P4 is recorded for the morning. Routing policies should also scope by source, by client, by time window (an overnight-only policy that handles crossing midnight), and by keyword — "disk" alerts from one noisy client legitimately deserve their own quieter lane.
Suppress planned work with maintenance windows
Patch night should not page anyone. A maintenance window — one-off or recurring, scoped to specific sources or all of them — records arriving alerts as suppressed: visible in history, counted in reporting, paged to nobody. The distinction matters. Deleting alerts during maintenance hides real failures; suppressing them keeps the record while protecting sleep.
Invert the pattern for silent failures
The scariest failures fire no alert at all: the backup job that simply stopped running, the sync script that died three weeks ago. Heartbeat monitors invert alerting — the job pings a unique URL on every successful run, and if the expected interval plus a grace period passes silently, that raises an alert through the normal routing. The next successful ping resolves it automatically.
Make alerts survive the shift change
This is the piece almost no alerting tool has an answer for. An alert acknowledged during a shift is a commitment — and commitments need to transfer when the person leaves. The mechanism that works is the same one that works for tickets: a structured handoverthat forces a decision. At sign-off, every open alert must be explicitly resolved or carried forward into the incoming engineer's brief. "Silently dropped" stops being a possible state.
Measure noise per client — then bill the fix
Once alerts flow through one accountable pipeline, you get a dataset most MSPs have never seen: which clients generate the noise, and what it costs to serve them. A per-client view of alert volume, duplicate/flapping share, after-hours pages, and how often anyone actually acted on an alert tells you where tuning effort pays off first. A client with high volume and a ninety-percent noise share is a threshold-tuning problem. A client whose same server fired thirty-four disk alerts this quarter is a project proposal — bring that chart to the QBR and the hardware conversation has already made itself.
The tooling question
General-purpose paging tools — PagerDuty, Better Stack, Squadcast — do routing and escalation well, but they are built for software teams: no PSA integration, no per-client cost-to-serve lens, no handover story, and per-user pricing that was designed for SRE headcounts. Opsgenie, the old MSP default, shuts down in April 2027.
Shiftctl's Enterprise plan implements the model in this guide as one system: alert ingestion from ConnectWise Automate, Datto RMM, N-able, PRTG, or any tool that can POST a webhook; routing driven by the same on-call schedule that runs your handovers; multi-step escalation over SMS, Slack, Teams, email and push; maintenance windows, heartbeat monitors, per-client noise reporting with a QBR export — and the sign-off step that makes an open alert impossible to drop between engineers.
Implementation checklist
- Pick one pipeline — every alert source POSTs to the same place, no side channels
- Connect each RMM/monitoring source and send a test alert end-to-end
- Verify every engineer's SMS/push channels actually reach them before relying on them
- Define P1–P4 and write down the paging contract for each tier
- Build one hard escalation ladder for P1/P2 and one quiet lane for P3/P4
- Create recurring maintenance windows for patch cycles before the first patch night
- Add heartbeats to every backup and sync job that matters
- Make sign-off force a resolve-or-carry decision on every open alert
- Review the per-client noise report monthly; tune the worst offender each cycle
Frequently asked questions
How do I get RMM alerts to the on-call engineer automatically?
Point your RMM's webhook or HTTP notification action at an alerting layer that reads your on-call schedule. The alert should page whoever the schedule says is responsible at that moment — over SMS, push, or chat — and escalate if they don't acknowledge. Email-to-ticket alone fails after hours because nobody is watching the queue.
How do MSPs reduce alert noise?
Three moves cover most of it: severity tiers so only P1/P2 pages anyone, maintenance windows so planned work never pages, and a per-client noise report so tuning effort goes where the duplicates and flapping actually come from. Deduplication of re-firing monitors should be automatic — one open alert per issue regardless of how often the monitor re-sends.
What happens to open alerts at shift change?
In most setups, nothing — which is the problem. The fix is a structured handover that forces a decision: at sign-off, every open alert is either resolved or explicitly carried into the next engineer's brief, so the incoming engineer sees what is still burning before they go on-call.
Do I still need PagerDuty if I have an RMM?
An RMM notices problems; it does not manage who gets woken up, whether they responded, or what happens if they don't. You need a routing and escalation layer on top. That can be PagerDuty, or — if your paging runs on SMS and chat rather than voice calls — an MSP-focused tool like Shiftctl that also carries alerts through shift handovers and syncs tickets to your PSA.
Your RMM notices. Shiftctl makes someone accountable.
Route Automate, Datto RMM, N-able and PRTG alerts to the engineer on call, escalate until acknowledged, and carry anything still open into the next shift's handover brief. Alerting is part of the Enterprise plan.