The Bullhorn Outage Playbook: How MSPs Detect and Respond When a Critical SaaS Platform Goes Dark

The Register reported this week that Bullhorn — the staffing and recruitment platform thousands of agencies run their entire business on — was knocked offline by a cyberattack. CrowdStrike has been called in. Customers are staring at login failures, and the question of whether data was stolen remains open.

If you support a staffing client, you know exactly what that morning looked like on your side. The phones went first. Then the tickets. Then someone asked whether it was your firewall. You found out the way IT teams always find out about third-party outages: from a receptionist, not from a monitor.

That gap — between a platform dying and you knowing about it, knowing the blast radius across your client base, and getting a status update out the door — is where MSP profitability and client trust are won or lost. This post breaks down why that gap exists, what it actually costs, and how to close it.

The Problem: Your Stack Watches Your Servers. Nothing Watches Your Vendors.

Look at the average MSP toolchain: a PSA like ConnectWise Manage or Autotask, an RMM like NinjaOne or N-able, maybe standalone monitoring in PRTG or SolarWinds, a separate helpdesk, and a patching product bolted on the side. Each tool sees one slice of reality. None of them owns the question your client is actually asking: is the thing my business runs on up?

Your RMM agents see endpoints, servers, and Windows services. An external SaaS login page is not something they check. Your monitoring tool might have a URL sensor buried in it, but its alerts don't create tickets, don't know which of your 40 clients depend on that vendor, and don't route to anyone. Your helpdesk has zero telemetry — so every 'is it down for you too?' ticket has to be triaged by a human opening tabs.

The timeline every tech recognizes

• 9:41 — the vendor starts returning 503s. Nobody at the MSP notices.
• 9:58 — first ticket: 'Client can't log in.' A tech asks the user to reset their password.
• 10:15 — tickets are piling up across three clients. Someone finally checks Downdetector and the vendor's status page.
• 10:40 — you're confident it's the vendor. A senior tech is manually drafting status emails, client by client.
• 11:30 — the last client finds out, because their account manager was in a meeting.

Detection took an hour. Triage ate a technician for the morning. And the SLA clock was running the entire time on contracts you couldn't see, because SLA data lives in the PSA while the evidence lives everywhere else.

Do the math on the ticket flood: 300 end users hitting 'can't log in' at four minutes of triage each is 20 tech-hours burned on tickets that should have been one incident and one status update. That's a day of capacity gone, real tickets stuck behind the flood, and two techs who were already tired now doing archaeology instead of fixing anything.

Why this keeps happening

• Siloed architecture. RMM, monitoring, helpdesk, and patching were bought separately, don't share a data model, and correlate nothing. No tool can say 'this alert caused these tickets across these clients.'
• Per-client blindness. Most tools make you check client by client. Answering 'how many clients are affected?' means clicking through consoles while the answer gets stale in real time.
• No dependency visibility. Nothing maps which client sites, circuits, and applications depend on which vendor — so you can't instantly separate 'vendor is down' from 'our client's circuit dropped,' and you burn the first 30 minutes proving it.
• Vendor concentration cuts both ways. Bullhorn's outage hits your clients. But a ConnectWise, Autotask, or NinjaOne outage hits you — and if your helpdesk is the thing that's down, you're triaging from a personal inbox while clients call your cell. Every disconnected tool in your stack is another Bullhorn waiting to happen.

How AlertMonitor Changes the Timeline

AlertMonitor was built multi-tenant from day one for exactly this scenario, and it collapses the fragmented scramble into one console.

Outside-in availability checks per client. Define HTTP/HTTPS, DNS, and TCP checks for each client's business-critical SaaS — login portals, ERPs, auth endpoints. AlertMonitor probes them continuously and alerts on latency degradation and consecutive failures, so you hear about a dying platform at minute one, not when reception calls.

One NOC view, instant blast radius. When a shared platform degrades, correlated alerts from every affected client land in a single unified view: 14 clients affected, grouped as one incident — not 14 tabs and 40 open tickets.

Per-client alert routing and SLA thresholds. One incident fans out automatically to the right service desk queues and account managers, with escalation policies matched to each client's SLA tier. No client finds out from their own users first.

Alert-to-ticket in one click, with merging. The flood of 'can't log in' tickets gets merged into one master incident ticket. Twenty tech-hours of triage becomes fifteen minutes.

Mass client communication from the incident. Push one status update to every affected client directly from the incident record — at 9:50, not 11:30.

Topology mapping to rule yourself out fast. Before you blame the vendor, the network map shows you in seconds whether the client's circuit, firewall, or app servers are actually healthy.

RMM, patching, and remediation in the same console. When a workaround exists — restart a service, push a config, flip endpoints to a backup path — you execute it without switching tools. And because AlertMonitor consolidates RMM, monitoring, helpdesk, and patching, your own operational stack carries fewer vendors and fewer ways to go dark underneath you.

What You Can Do Today

1. Inventory client-critical SaaS dependencies. One spreadsheet: client, platform, login URL, who to notify, SLA tier. Ask each client one question: what stops your business if it's down? For staffing clients the answer is Bullhorn; for others it's their ERP, Microsoft 365, or a vertical app.

2. Stand up an outside-in availability check right now. You don't need to wait for a platform rollout — start with a scheduled script running from a probe outside the client network:

# Outside-in availability check for client-critical SaaS endpoints
# Run from a probe OUTSIDE the client network (Azure VM, office box, etc.)
$endpoints = @(
    @{ Name = 'Bullhorn Login';    Url = 'https://login.bullhorn.com' },
    @{ Name = 'Client ERP Portal'; Url = 'https://portal.acme-erp.com/login' },
    @{ Name = 'M365 Auth';         Url = 'https://login.microsoftonline.com' }
)
$logFile = 'C:\Monitoring\saas-dependency-log.csv'

foreach ($ep in $endpoints) {
    $sw = [System.Diagnostics.Stopwatch]::StartNew()
    try {
        $resp = Invoke-WebRequest -Uri $ep.Url -Method Head -UseBasicParsing -TimeoutSec 10
        $sw.Stop()
        $status = $resp.StatusCode
    }
    catch {
        $sw.Stop()
        $status = 'FAILED'
    }

    [PSCustomObject]@{
        Timestamp = (Get-Date).ToString('yyyy-MM-dd HH:mm:ss')
        Endpoint  = $ep.Name
        Url       = $ep.Url
        Status    = $status
        LatencyMs = $sw.ElapsedMilliseconds
    } | Export-Csv -Path $logFile -NoTypeInformation -Append

    Write-Output ('{0}: {1} ({2} ms)' -f $ep.Name, $status, $sw.ElapsedMilliseconds)
}

The CSV log matters: when the vendor later asks for evidence or a client disputes your response time, you have a timestamped record instead of a memory.

3. Rule yourself out before you blame the vendor. The worst 30 minutes of any vendor outage is proving it's not your side:

# Confirm DNS resolution and TCP 443 reachability to the vendor
Test-NetConnection -ComputerName 'login.bullhorn.com' -Port 443 |
    Select-Object ComputerName, RemoteAddress, TcpTestSucceeded

# Verify the app-tier service is healthy on the client's own servers
$servers = 'APP01', 'APP02', 'APP03'
Invoke-Command -ComputerName $servers -ScriptBlock {
    Get-Service -Name 'AcmePortal' | Select-Object Name, Status
} | Format-Table -AutoSize

4. Get a second vantage point. A quick outside-in check from a Linux probe confirms whether the failure is global or local to one network:

for url in https://login.bullhorn.com https://portal.acme-erp.com/login; do
  code=$(curl -s -o /dev/null -w "%{http_code}" --max-time 10 "$url")
  time=$(curl -s -o /dev/null -w "%{time_total}" --max-time 10 "$url")
  echo "$url -> HTTP $code, ${time}s"
done

5. Wire the workflow, not just the check. In AlertMonitor: create the availability check → set per-client alert routing → attach it to the client's SLA threshold → save a client comms template linked to the incident type 'SaaS outage.' The next Bullhorn-style event should cost you one alert, one master ticket, and one status update.

6. Shrink your own vendor list. Every console you consolidate removes a dependency, a per-seat license, and a context switch. That's the quiet, compounding win of running RMM, monitoring, helpdesk, and patching in one platform — fewer tools to break, fewer tabs to juggle, fewer logins to lose in an incident.

The Bullhorn outage will get patched, CrowdStrike will publish its findings, and six months from now another vendor will go dark. The MSPs who look good that day won't be the ones with more tools open — they'll be the ones who knew first, saw the blast radius immediately, and had every client notified before their users finished complaining.

Related Resources

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