ConnectWise Suspends Three Services: The MSP Playbook for Surviving a Vendor Incident Without Going Blind

If you run an MSP, the ConnectWise announcement didn't read like news — it read like your next two weeks.

Here's where things stand: attackers abused application identities to reach Microsoft 365 customer tenants through ConnectWise's platform. In response, ConnectWise suspended three services — Cloud Backup, SaaS Security, and Cloud Management. As of October 19, all three remain offline with no restoration date announced. ConnectWise reports no evidence that stored backup archives were accessed, and MSPs are expected to investigate their own tenants and their customers' tenants.

Translation for the NOC: your backup console, your SaaS security layer, and your M365 management plane went dark simultaneously. Clients are emailing. The helpdesk queue is growing. And the tools you'd normally use to triage this are the tools that got suspended.

This post is the playbook for that week — what to check, in what order, and how to make sure your visibility into client environments never again depends on a single vendor's control plane.

Why This Incident Hits MSPs So Hard

An internal IT team dealing with a vendor incident has one tenant to protect. You have thirty. Or sixty. Or two hundred. The same event creates four simultaneous operational fires:

1. The verification scramble. ConnectWise is telling MSPs to investigate their own and their customers' tenants. If the only way your team touched those tenants was through Cloud Management, you may not have standing access, current credentials, or GDAP relationships ready to go. Now you're signing in tenant by tenant — 20 to 30 minutes each once you count MFA, documentation lookups, and notes. At 40 clients, that's 13–20 hours of your most senior people, burned entirely on due diligence instead of client work.

2. The backup SLA problem. You can't run, schedule, or verify backup jobs from Cloud Backup right now, and there's no restoration ETA. If your contracts carry RPO commitments — "incrementals every 4 hours," "monthly restore tests" — those commitments are currently unverifiable from the vendor console. "No evidence that backup archives were accessed" will satisfy a client for about a week. After that they want proof, and proof means independent checks: last successful backup timestamps, backup agent service states, job logs read straight off the servers.

3. The monitoring blind spot. If you used Cloud Management to watch Microsoft 365 health across clients, that signal is gone — exactly when you need it most. This is the classic failure mode of monitoring that lives inside the platform being monitored: the incident knocks out the thing and the thing watching the thing at the same time.

4. The ticket flood. "Did this affect us?" arrives from every client with an M365 tenant — which is all of them. Without a helpdesk linked to your monitoring and asset data, tracking who's been notified, which tenants are cleared, and who's still waiting becomes a spreadsheet project: three CSV exports and a VLOOKUP, assembled by someone who should be remediating instead.

Add it up: senior techs doing manual tenant audits for days, response times sliding past SLA targets because the queue tripled overnight, and an ops manager who genuinely cannot answer "are all 60 clients covered?" with a straight face. This is how MSPs lose accounts — not because they failed to secure something, but because they couldn't demonstrate control quickly.

The Structural Problem: Concentrated Vendors, Disconnected Tools

None of this happens because MSP technicians are sloppy. It's structural.

Vendor concentration was a deliberate efficiency trade. Buying backup, security, and M365 management alongside your RMM means one invoice, one console, one integration to maintain. Genuinely efficient — until one incident suspends three capabilities at once. Concentration risk never shows up on the quote; it shows up at 2am when everything sharing a control plane goes down together.

Monitoring got coupled to management. Many MSPs let monitoring ride along with the management platform. But when the management plane is the problem, your eyes are the first casualty. Visibility needs to come from an independent plane that keeps watching whether any particular vendor console is up or not.

The helpdesk doesn't talk to the monitoring. During an incident, the questions are operational: which clients are affected, who have we contacted, what's the status per tenant? When monitoring lives in one tool, tickets live in another, and assets live in a third, every answer is a manual merge. That's why the same incident costs one MSP six hours of triage chaos and another thirty minutes.

No real per-client operational model. Tools built for a single enterprise bolt multi-tenancy on as an afterthought. Per-client SLA thresholds, per-client alert routing, a unified NOC view across every client — during a vendor incident these aren't nice-to-haves. They're the difference between filtered triage and tab-hunting across a dozen browser windows.

How AlertMonitor Changes the Vendor-Incident Workflow

AlertMonitor was built for the MSP model from day one — and a week like this is exactly what that design pays off in.

An independent monitoring plane. AlertMonitor agents watch your clients' servers, workstations, and services directly: disk, CPU, critical services, event logs, backup job outcomes. Your visibility into backup health doesn't depend on the backup vendor's console answering. When Cloud Backup suspends, you still have checks confirming backup services are running and last-success timestamps aren't going stale. You can even monitor the suspended platform itself — a service check on the vendor's agent tells you the moment anything changes.

One NOC view across every client. Multi-tenancy here isn't a feature; it's the architecture. Isolated per-client dashboards, a unified cross-client view, per-client alert routing, per-client SLA thresholds. When an incident hits, you filter to affected clients in seconds instead of opening client consoles one at a time.

The helpdesk lives in the same platform. Create one master incident for the vendor event, link child tickets per client, and connect each ticket to the monitoring and asset data that justifies it. The "who have we notified, who's still open" report is a filter click, not a CSV merge. SLA clocks run per client, so you see which conversations are approaching breach before they breach.

RMM and patching that don't share a fate with the breached vendor. You still need to push scripts, restart services, and roll out changes while another vendor's console is down. AlertMonitor's remote management and patch management run on their own platform, so remediation keeps moving.

Before and after, concretely. Old workflow: a dozen browser tabs across the RMM, the backup console, M365 portals, and a separate helpdesk. The impact list gets assembled by exporting client data from three tools and merging it. Each tenant is verified by manual sign-in. Status lives in a shared spreadsheet that's outdated by the time it's saved.

AlertMonitor workflow: one dashboard filtered to affected clients. Master incident created, child tickets linked per client, maintenance windows set on alert routing in two clicks. Verification output attached to each client ticket. Client updates sent from the ticket, communication history auditable, SLA timers running. The impact report the ops manager asks for at 9am already exists.

Teams consolidating RMM, monitoring, helpdesk, and patching onto one platform report the obvious wins — fewer context switches, faster alert-to-action — but the one that matters in weeks like this is different: when any single vendor has a bad day, you still have one complete, working console.

What to Do Right Now: The MSP Triage Checklist

Work through this in order.

1. Inventory which of your tenants hold ConnectWise application identities

Run this in your own tenant first, then repeat for each client tenant through your GDAP relationships or a per-tenant connection:

Connect-MgGraph -Scopes 'Application.Read.All'

Get-MgServicePrincipal -All |
    Where-Object { $_.DisplayName -match 'ConnectWise' } |
    Select-Object DisplayName, AppId, Id |
    Format-Table -AutoSize

Document every match, including when the consent was granted. As a Microsoft partner, also review grants made under your own partner application — that's how an incident in one vendor's platform ripples into client tenants. The output of this step, per tenant, becomes your due-diligence record for client communication.

2. Verify backup agent health straight from the servers

Don't trust a console that isn't answering. Check backup-related services directly across each affected client's servers:

$servers = Get-Content .\client-servers.txt
$results = foreach ($server in $servers) {
    $reachable = Test-WSMan -ComputerName $server -ErrorAction SilentlyContinue
    $svc = if ($reachable) {
        Invoke-Command -ComputerName $server -ScriptBlock {
            Get-Service | Where-Object DisplayName -match 'backup'
        }
    }
    [PSCustomObject]@{
        Server     = $server
        Reachable  = [bool]$reachable
        BackupSvcs = ($svc | ForEach-Object { '{0}={1}' -f $_.Name, $_.Status }) -join '; '
    }
}
$results | Export-Csv .\backup-agent-status.csv -NoTypeInformation
$results | Where-Object { -not $_.Reachable -or $_.BackupSvcs -match 'Stopped' }

Put the client's server names in client-servers.txt, one FQDN per line. The last line prints only the problem machines — that's your remediation queue.

3. Confirm last successful backup from the OS side

The console being offline doesn't mean backups stopped — but you need proof either way. On Windows servers, event ID 4 in the backup operational log marks a successful completion:

$lastGood = Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-Backup'
    Id      = 4
} -MaxEvents 1 -ErrorAction SilentlyContinue

if ($lastGood) {
    [PSCustomObject]@{
        Server      = $env:COMPUTERNAME
        LastSuccess = $lastGood.TimeCreated
        AgeHours    = [math]::Round(((Get-Date) - $lastGood.TimeCreated).TotalHours, 1)
    }
} else {
    "No successful backup event found on $env:COMPUTERNAME - investigate now."
}

Run it per server — or loop it with the script above — and you have client-ready evidence of backup freshness that exists entirely outside the suspended platform.

4. Separate Microsoft-side health from vendor-side suspension

Clients will conflate the ConnectWise suspension with "Microsoft 365 is down." Pull actual service health per tenant so your communication is precise:

Connect-MgGraph -Scopes 'ServiceHealth.Read.All'

Get-MgServiceAnnouncementHealthOverview |
    Select-Object Service, Status |
    Sort-Object Service |
    Format-Table -AutoSize

If M365 shows healthy, say so explicitly in client updates. It reassures, and it demonstrates you checked something real.

5. Run communication like an incident, not an inbox

Create one master incident in AlertMonitor's helpdesk, link a child ticket per client, and attach the verification output from steps 1–3 as you complete each one. Send client updates from the ticket so the communication history is auditable. This is where an integrated helpdesk stops being a convenience: "which clients are still waiting on their verification report?" should be a ticket-view filter, and in AlertMonitor it is — the master-incident view shows every linked client ticket with its SLA state on one screen.

6. Fix the structural exposure before the next one

Two moves, in this order.

First, make your monitoring plane independent of your management and backup vendors. Whatever handles backup, the alerts on agent status, job failures, and last-success age should come from a monitoring platform that keeps working when that vendor doesn't. In AlertMonitor that's a service check per server plus an event-log check on the backup log — configured once, deployed across all clients, routed per client.

Second, consolidate your own operational stack — deliberately. The two risks are not the same. Concentration inside one vendor's control plane (backup + security + M365 management suspended together) is what happened here. Tool sprawl across five disconnected platforms is its own incident tax: MSPs on fragmented stacks spent their worst hours this week exporting and merging data just to answer basic questions. One operational platform for monitoring, RMM, helpdesk, and patching — independent from your backup archive vendor — gives you a single working console when any other vendor has a bad day. That logic holds whether the rest of your stack is ConnectWise, NinjaOne, Kaseya, or Datto.

The Takeaway

The ConnectWise suspension will resolve. Services will come back, tenants will be cleared, and this will become a case study. What separates MSPs that keep client trust through it from the ones that bleed accounts is brutally simple: independent visibility, one working console, and the ability to produce evidence per client without a week of manual labor.

If your current stack means a vendor incident also takes down your monitoring, your ticketing, and your reporting, that's not a ConnectWise problem. That's an architecture problem — and it's fixable this quarter.

Related Resources

AlertMonitor MSP Operations & Team Efficiency AlertMonitor Platform Overview Book a Demo MSP Operations & Team Efficiency Resources