When Your RMM Goes Dark: Lessons From the ConnectWise Service Shutdown

If you run infrastructure for a living, this week's news landed where it hurts. The Register reported that ConnectWise took several of its SaaS services — backup, security, and management tools that thousands of MSPs rely on daily — offline while it investigates a security incident. Huntress, in parallel, alleged that Microsoft 365 accounts had been taken over in connection with the event. Credit where it is due: pulling services offline to contain a possible compromise is the responsible call from a security standpoint.

But from an operations standpoint, it is the scenario every IT team quietly fears: the tool you use to manage everything else became the thing that is down.

Think about what that means in practice. Your RMM is how you see your endpoints. It is how you remote into a user's laptop, how you push patches, how you run the PowerShell script that fixes the thing at 2 a.m. When it is unavailable — because of a vendor security investigation, an outage, or anything else — you do not just lose visibility. You lose hands. And your users, your ticket queue, and your SLA clocks do not pause while you figure out plan B.

What Actually Breaks When the RMM Disappears

Let's walk through a realistic hour-by-hour. You manage 250 endpoints across a handful of clients or departments. Three techs on shift. Around 30 open tickets.

Hour 1. The console will not load. Someone finds the vendor's status page. Automation — the nightly patch window, the disk-cleanup scripts, the scheduled reboots — is suspended. You have no way to know which jobs ran and which did not.

Hour 2. The queue grows. Users call in because Outlook is acting up and nobody can open a remote session. Your helpdesk keeps logging tickets — assuming it is a separate product — but every one of them now stalls on a callback promise.

Hour 4. A file server's data volume crosses 95% full. If your monitoring is a separate tool, it might catch it. But remediation means either driving to the office or walking a frustrated user through PowerShell over the phone. A five-minute script run becomes a two-hour ordeal.

End of day. Fifteen tickets blew their SLA. Two site visits are scheduled for tomorrow. The patch window you needed tonight gets deferred — again. And your team spends the evening writing the 'we are aware of an issue with a third-party provider' email.

For a team of three supporting 12 clients, one day without a functioning RMM easily consumes a week's worth of SLA headroom. Phone-based troubleshooting does not scale: at 10–15 minutes per endpoint contact, 50 affected users is a full day of one technician's capacity — gone. Multiply that across a client base, and technician burnout stops being an abstraction.

Why This Keeps Happening

The uncomfortable answer is architecture. Most IT stacks were not designed — they were accumulated.

• The RMM is a single point of failure by design. Every agent runs with SYSTEM-level rights. That is what makes RMM powerful, and it is also why RMM platforms are among the most targeted attack surfaces in the industry — Kaseya's 2021 REvil supply chain attack is the canonical example. A vendor taking services offline to investigate a suspected incident is correct behavior. It is also operationally devastating, and you should plan for it.
• Monitoring, RMM, and helpdesk are separate products stitched together. When they come from different vendors, they are held together by integrations that sync every 5–15 minutes — or break silently. Your monitoring tool can scream about a down server while your RMM shows nothing, and your helpdesk has no idea either way. Each integration is one more dependency that fails when the core vendor does.
• Context lives in five places. The alert is in the monitoring tool, the device history is in the RMM, the user's ticket is in the helpdesk, the patch state is in yet another console, and the actual fix happened in a technician's head. Reconstructing any incident means tab-switching, copy-pasting device names, and hoping the timestamps line up.

That last point is the everyday tax most teams pay even when nothing is wrong. The outage just makes it impossible to ignore.

How AlertMonitor Changes the Equation

AlertMonitor was built on a different premise: monitoring, RMM, helpdesk, patching, and network topology in one platform, one agent story, one timeline. That is not a feature checklist — it is the difference between 'we got an alert' and 'we fixed it.'

Here is the same disk-full scenario, handled inside AlertMonitor:

1. The alert fires on SERVER-FS01: data volume at 96%, projected full in 14 hours.
2. The on-call tech clicks through from the alert to the device view — live metrics, patch compliance, open tickets, and recent activity for that machine in one place.
3. No remote session is even needed for this class of issue: the tech selects the disk-cleanup script from the library and runs it against the device — or against the whole 'File Servers' device group if the pattern is spreading.
4. Script output lands directly in the monitoring timeline. The free-space metric recovers, the alert auto-closes, and the ticket — created from the same alert, in the same system — gets resolved with the full before-and-after visible to anyone who asks.

Elapsed time: minutes. No tab switching, no exported logs, no guessing which tool has the real status.

The broader points for teams reading this week's headlines:

• Fewer dependencies, fewer failure modes. Every separate console you run is another vendor that can go dark, another integration that can break, another status page to watch. Consolidating monitoring, RMM, and helpdesk into one platform does not eliminate risk — but it collapses the dependency chain that turns one vendor issue into a full-stack outage.
• Script results become monitoring data. Automated remediations and manual technician actions both show up in the same timeline. That is your audit trail, your SLA evidence, and your post-incident review material — generated automatically instead of reconstructed from memory.
• Patch state lives next to the alert. When a patch window gets deferred because the tooling was down, that shows up as a measurable compliance gap in the same platform — something you can report on and reschedule, not a memory of what was supposed to happen.
• MSPs get one NOC view across all clients. When a vendor event hits, you check one dashboard instead of five, and you can see instantly which clients and device groups are affected.

Practical Steps You Can Take This Week

1. Map your management-plane dependencies. Write down, honestly: if your RMM console became unavailable right now, what stops? Remote sessions? Patch pushes? Scripted remediation? Alerting itself, if it comes from the same vendor? Score each capability by how many endpoints and clients it touches. Anything critical that has exactly one path is a risk you have now named.

2. Build and test break-glass access. Local admin credentials in a vault (or LAPS-managed), a jump host reachable without the RMM, and documented VPN access for at least two people per team. Test it quarterly — an untested break-glass procedure is a rumor, not a plan.

3. Keep a fleet-health script library you can run from anywhere. These should live in AlertMonitor's script engine on a schedule — but keep copies you can execute locally in a degraded scenario. Three every team should maintain:

Disk space across the server fleet, so you find the 95%-full volume before it becomes a 2 a.m. page:

$servers = 'DC01','FS01','SQL01','APP01'
Get-CimInstance -ComputerName $servers -ClassName Win32_LogicalDisk -Filter 'DriveType=3' |
  Select-Object SystemName, DeviceID,
    @{n='SizeGB';e={[math]::Round($_.Size/1GB,1)}},
    @{n='FreeGB';e={[math]::Round($_.FreeSpace/1GB,1)}},
    @{n='FreePct';e={[math]::Round($_.FreeSpace/$_.Size*100,1)}} |
  Where-Object { $_.FreePct -lt 15 } |
  Sort-Object FreePct

Critical service check with automatic restart — the script that turns a helpdesk ticket into a non-event:

$targets  = 'WKS-101','WKS-102','WKS-103'
$services = 'Spooler','wuauserv','WinRM'
foreach ($t in $targets) {
  foreach ($s in $services) {
    $svc = Get-Service -ComputerName $t -Name $s -ErrorAction SilentlyContinue
    if ($svc -and $svc.Status -ne 'Running') {
      Restart-Service -InputObject $svc -Force
      Write-Output ('{0} : {1} was {2} - restarted' -f $t, $s, $svc.Status)
    }
  }
}

Patch staleness check — how long since each machine last installed a hotfix, so deferred patch windows become visible numbers:

Get-CimInstance -ClassName Win32_QuickFixEngineering |
  Where-Object { $_.InstalledOn } |
  Sort-Object InstalledOn -Descending |
  Select-Object -First 1 CSName, HotFixID, InstalledOn,
    @{n='DaysSincePatch';e={(New-TimeSpan -Start $_.InstalledOn -End (Get-Date)).Days}}

And for the Linux side of the house, a quick service guard:

#!/bin/bash
# Restart nginx if it is not active, and log the result
if ! systemctl is-active --quiet nginx; then
  systemctl restart nginx
  logger 'nginx was inactive - restarted by fleet-health script'
  echo 'nginx was inactive - restarted'
else
  echo 'nginx is running'
fi

4. Rehearse the degraded mode. Once a quarter, run a one-hour drill with the RMM console off the table. Who calls whom? How do you reach endpoints? How do you verify a fix? You will surface the gaps in a controlled hour instead of during a live incident.

5. Consolidate where consolidation reduces risk. Fewer tools means fewer integrations, fewer vendors to monitor, and one place where the alert, the action, and the evidence live together. When you evaluate platforms, weight 'how many moving parts does this replace?' as heavily as the feature grid.

The Takeaway

Nobody should second-guess a vendor for isolating services during a security investigation — that is what a responsible vendor does. But this week is a reminder that your management plane is production infrastructure, and it deserves the same resilience planning as the servers it manages. Map the dependencies, script the routine work, rehearse the outage, and run your monitoring, RMM, and helpdesk close enough together that an alert and its fix live in the same place.

Because the next time a status page turns red, the teams that recover fastest will not be the ones with more tools. They will be the ones whose tools talk to each other — and whose technicians can go from alert to remote session to verified fix before the user finishes writing the ticket.

Related Resources

AlertMonitor RMM & Remote Management AlertMonitor Platform Overview Book a Demo RMM & Remote Management Resources