48,000 CVEs, Five Days to Exploit: Why Your On-Call Alerting Matters More Than Patching Everything

Patch Tuesday used to be the metronome of IT operations. Updates landed on schedule, you tested them, the change board nodded, and deployments rolled out over the following weeks. It wasn't fun, but it was predictable.

That predictability is gone. Computerworld's recent piece on what practitioners are calling the "Patch Apocalypse" puts hard numbers on what every sysadmin already feels: nearly 48,000 CVEs were published in 2025, and the average time from disclosure to active exploitation has collapsed to roughly five days. AI is accelerating vulnerability discovery on both sides — attackers and defenders alike. Your weekly CAB meeting and your two-week staging ring are not part of the attacker's timeline.

Here's what that means if you're the one carrying the pager: you cannot patch everything. Your RMM will never sustain 100% compliance, and chasing it means emergency reboots of production servers at 2am because a scanner flagged 60 new "highs" overnight. When you can't fix everything, the only thing standing between you and a breach headline is knowing — within minutes, not days — which of the things you didn't patch just got hit. That is an alerting problem, not a patching problem. And most alerting is broken.

Everything Is Critical, So Nothing Is

Look at the typical tool stack in a mid-size IT shop or an MSP NOC and count the disconnects:

• Standalone monitoring (PRTG, Zabbix, SolarWinds) has no idea what an asset's patch state is or whether it faces the internet. A lab VM and the internet-facing RDS gateway trigger the same "Critical" severity and route to the same inbox.
• RMM patch modules (ConnectWise Automate, NinjaOne, Datto RMM) happily report "patch compliance: 87%." At 2am, 87% is useless. What you need is the list of the 13 exposed machines and whether any of them are the ones attackers actually want. Getting that list means exporting CSVs and cross-referencing a KEV feed by hand.
• The helpdesk (ConnectWise Manage, Freshservice, HaloPSA) has no idea a monitor fired. Alerts go to email, tickets get created by hand — or not — and your SLA report is a spreadsheet stitched together from two systems that don't share a timeline.

Why does this happen? These tools were built in different eras by different vendors and "integrated" with email notifications and webhook duct tape. The alert path looks like this: monitor sends email → inbox rule tags it → someone eventually sees it → someone remembers to check the RMM → someone opens a ticket. There's no deduplication, so when a core switch flaps, the on-call phone gets 60 "device offline" pages instead of one root-cause alert. There's no maintenance-window awareness, so every Patch Tuesday reboot storm pages whoever is on rotation with exactly the downtime they were told to expect.

The operational math is ugly. Teams running email-based alerting routinely see mean time to acknowledge in the 20–45 minute range — when the page gets seen at all. Every MSP tech knows this scenario: the night tech receives 140 alerts across 12 clients. Alert #97 in the queue is a domain controller whose system drive hit 4% free. Alerts #1–96 are backup notices, a flapping VPN tunnel, and a printer that's been "offline" since 2019. Which one gets found first?

Layer the Patch Apocalypse on top and the picture gets worse. A change board that meets weekly cannot respond to a five-day exploit window, so emergency patching becomes the norm. Emergency patching at 2am becomes the norm. And "the monitoring tool woke me up for a toner level" becomes the sentence that sends your best tech browsing job listings. The cost shows up as missed SLAs, 9-hour MTTRs on the one incident that mattered, and turnover you can't afford.

What Risk-Based On-Call Actually Looks Like

If you can't patch 48,000 CVEs, you triage. The same logic applies to alerts: the answer isn't more alerts, it's better signal. This is the insight AlertMonitor was built on — alert fatigue isn't a volume problem, it's a signal quality problem.

Every alert carries full context. Device, client, what changed, and what healthy looks like on that specific asset. CPU at 92% pages you on a domain controller that normally idles at 12% — but never fires on the app server that has honestly run at 85% every business day for a year. The tech stops triaging across four browser tabs, because the alert itself contains what used to take 20 minutes to find.

Severity follows risk, not raw thresholds. Because monitoring, RMM, and patch state live in the same platform, an alert can weigh asset criticality and exposure. Internet-facing server, missing an actively exploited KB, service degraded → P1, page now. Lab workstation, same missing KB, running fine → ticket, no page. That's the difference between 140 alerts a night and the 6 that matter.

Smart deduplication kills the cascade. When a root-cause event fires, downstream symptoms are correlated and suppressed. One switch flap is one alert, not sixty. The on-call tech acknowledges once instead of mass-dismissing a page storm — and accidentally dismissing the real problem hiding inside it.

Maintenance windows actually suppress. Schedule the patch window in AlertMonitor, and expected reboots and service restarts generate zero pages. Then automatic verification kicks in: did the server come back, did the critical services actually start? If yes — silence, and patch compliance updates itself. If no — that's a real alert with full context, routed to a human. Patch night stops being a night of pages about your own change process.

Multi-level on-call routing replaces the inbox. Escalation policies route by client, severity, and asset tier. Unacknowledged for 10 minutes? It escalates automatically to the next level. Nobody's personal inbox is your escalation system anymore.

Here's the before-and-after on one workflow:

The old way: Disk alert email fires at 02:14 → nobody sees it → tech opens the inbox at 07:30 → spends 20 minutes working out which server, which volume, how bad → opens an RMM session → opens the helpdesk and creates a ticket by hand → runs cleanup → documents it. Total cost: overnight exposure plus 90 minutes of work, and an SLA report that shows a 5-hour response time because the clock started when a human read an email.

With AlertMonitor: Trend detection flags the volume filling at 22:40, before it's critical → ticket auto-created with device, client, volume, and growth rate → on-call paged once, with full context → remote session launched from the same console → cleanup run → auto-verification confirms the disk is back under threshold → ticket closed at 23:10. MTTR: 30 minutes, all of it inside one timeline your SLA report can actually measure.

Practical Steps You Can Take This Week

1. Measure your noise before anything else. Pull the last seven days of alerts and bucket them by source and severity. In most environments, three or four sources generate 80% of the volume — usually backup notices, informational Windows events, and flapping sensors. Kill them, downgrade them, or deduplicate them. Every junk alert you remove makes the next real one louder.

2. Tier your assets and make escalation follow the tier. Tag your domain controllers, internet-facing systems, and primary business apps as P1-capable. Lab machines and lobby printers never wake anyone up. If your alerting tool can't express that rule, that's your first buying criterion.

3. Wrap every patch window in suppression plus verification. In AlertMonitor, attach the patch window to the server group, enable suppression, and enable post-patch service verification — then a reboot becomes a completed change instead of a gamble. A reboot is not a verified change until the services that matter are actually back:

# Post-reboot verification after a patch cycle — fail loudly if a critical service didn't come back
$server   = 'SQL01'
$services = @('MSSQLSERVER','SQLSERVERAGENT','Netlogon','DNS')

foreach ($svc in $services) {
    $s = Get-Service -ComputerName $server -Name $svc -ErrorAction SilentlyContinue
    if (-not $s -or $s.Status -ne 'Running') {
        Write-Warning "$server :: $svc is NOT running — escalate, do not close the change"
    } else {
        Write-Host "$server :: $svc OK"
    }
}

4. Manage to the exposed-machine list, not the compliance percentage. When a new actively exploited vulnerability drops, you need names, not averages:

# Which production servers are missing the KB that just went actively exploited?
$servers = Get-Content .\production_servers.txt
$kb      = 'KB5044284'

$missing = foreach ($srv in $servers) {
    $patched = Get-HotFix -ComputerName $srv -ErrorAction SilentlyContinue |
        Where-Object HotFixID -eq $kb
    if (-not $patched) {
        [PSCustomObject]@{
            Server    = $srv
            MissingKB = $kb
            CheckedAt = Get-Date -Format 'yyyy-MM-dd HH:mm'
        }
    }
}

$missing | Sort-Object Server | Format-Table -AutoSize
# Anything internet-facing in this list is tonight's priority. The rest can wait for the normal cycle.

5. Catch the disk before the disk catches you. The classic 2am page is a full volume that looked "fine" at 5pm. Sweep the fleet proactively:

# Find any volume under 15% free across the server fleet — before the on-call phone does it for you
$servers = Get-Content .\production_servers.txt

Get-CimInstance -ComputerName $servers -ClassName Win32_LogicalDisk -Filter 'DriveType=3' |
    Select-Object @{n='Server';e={$_.PSComputerName}},
                  @{n='Drive';e={$_.DeviceID}},
                  @{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 |
    Format-Table -AutoSize

And for the Linux side of the fleet, confirm whether the last patch cycle left a reboot pending before you assume you're compliant:

# Did the last patch cycle leave a reboot pending? (Ubuntu/Debian)
if [ -f /var/run/reboot-required ]; then
  echo "REBOOT REQUIRED — pending packages: $(cat /var/run/reboot-required.pkgs 2>/dev/null | tr '\n' ' ')"
else
  echo "No reboot required"
fi

6. Wire alerts into the helpdesk automatically. Every alert that survives your noise cleanup should become a ticket with its full context attached. If your techs are copy-pasting monitor output into ticket descriptions, you're paying them to act as an integration layer between two products that should have been one.

None of this requires the Patch Apocalypse to slow down — it won't. CVE counts will keep climbing, exploit timelines will keep shrinking, and "patch everything" will stay a fantasy. The teams that get through this aren't the ones patching fastest. They're the ones that know, in minutes, which three systems out of five hundred are actually exposed — and get woken up only when one of those three matters. Signal, not noise. That's the whole game.

Related Resources

AlertMonitor Alert Management & On-Call Operations

AlertMonitor Platform Overview

Book a Demo

Alert Management & On-Call Operations Resources