Patch Compliance Theater: When Your RMM Says "Deployed" but Half Your Fleet Is Still Missing Updates

David Heinemeier Hansson — the creator of Ruby on Rails — took a public roasting from The Register this week over an AI-coded "bakeoff" in which agents built the same app in different languages. Rust came out looking spectacular; readers quickly found the comparisons "curious." The benchmarks weren't apples-to-apples, and the person publishing the numbers had a clear stake in the outcome.

That story sounds like developer-world drama. It isn't. It is a perfect mirror of how patch management actually works in most IT shops: the tool reporting your compliance is the same tool whose work is being graded, and nobody independently verifies the result.

Your RMM claims 96% patch compliance. The report goes in the audit binder. Then a machine marked "successfully patched" gets hit by an exploit Microsoft fixed two months ago — or a "successful" .NET update reboots a file server at 2am and leaves a critical service down until someone in accounting opens a ticket at 8:12am.

Here is the truth practitioners learn the hard way: deployed is not patched, patched is not rebooted, and rebooted is not healthy. If your tooling collapses those four states into one green percentage, you don't have patch management. You have patch compliance theater.

The Problem: Dashboards Measure Attempts, Not Outcomes

Ask yourself what your patch report actually measures. In most environments, it's one of these:

• "Deployment succeeded" — meaning the RMM or WSUS pushed the job and got an OK at the transport layer. Whether the update actually installed, failed silently, or is sitting dormant waiting for a reboot is a different question the report never asks.
• "Needed count is zero" — the classic WSUS lie. A client's scan stops reporting and the server happily shows nothing needed. The machine is months stale; the dashboard stays green.
• "Compliance snapshot from last scan" — the scan ran during the deployment window while half the fleet was offline. Laptops that were asleep got skipped, got no retry, and quietly dropped out of the denominator instead of showing as failures.

And the states that matter most aren't tracked at all:

• Pending reboot — the update is technically installed but not active. Until that machine restarts, it is still running the vulnerable binary. Most patch reports never surface this as its own state.
• Failed installs that stay failed — 0x800f0922, a stuffed component store, a disk full of WinSxS. The job logs an error, nobody owns it, and that same KB re-fails for six straight months.
• Post-patch health — the update installed and the machine rebooted, but the application on it didn't come back cleanly. That's a monitoring question, and the patch tool never asks it.

Why the Gap Exists

Because the tooling was never designed as one system.

WSUS is a distribution mechanism from a different era with reporting bolted on afterward. SCCM's compliance views are only as fresh as the last hardware scan. Standalone RMM patch modules treat patching as a scheduled job queue: fire the deployment, log the result, move on. And your monitoring platform — PRTG, Zabbix, SolarWinds, whatever you run — has no idea a deployment window even exists. When the 2am reboot takes a service down, monitoring pages a mystery: "Service down on SRV-FS01." It cannot say why. So the tech opens the patch console in a second tab, the helpdesk in a third, WSUS in a fourth, and starts correlating by hand at an hour when correlation skills are at their worst.

Multiply that across a Patch Tuesday cycle: 400 Windows endpoints, a rack of servers, and third-party agents — Chrome, Zoom, Adobe, 7-Zip — tracked in yet another tool or nowhere at all. A two-person team burns two to three days per cycle chasing reboots, re-running failed deployments, and fielding the only question users actually ask: "is my computer going to restart on me today?"

The business impact is measurable:

• Longer outages. An uncorrelated reboot-outage gets diagnosed reactively, adding 30–90 minutes of MTTR per incident versus one where the alert already contains the patch context.
• Ticket noise. Every surprise reboot becomes a helpdesk ticket instead of a pre-communicated maintenance event.
• Audit risk. The compliance number in your report and the number your vulnerability scanner produces don't match, and you get to explain the delta to an auditor.
• Burnout. Skilled techs doing CSV-export archaeology at 8am instead of fixing anything.

And it's getting worse, not better. AI-accelerated development means more software shipping more releases — every vendor, every agent, every third-party utility in your stack. The patch queue grows every quarter. Headcount doesn't. Manual verification of "what actually shipped" cannot scale, and curated dashboards will not volunteer the truth.

How AlertMonitor Makes Patch Status Real

AlertMonitor was built on a different premise: patch state is a live operational signal, not a monthly report. The patch management module tracks the patch status of every managed Windows device in real time — which machines are missing updates, which have failed patches, and which are pending a reboot — each as its own explicit state. "Pending reboot" never hides inside "compliant."

Three integrations change the outcome:

1. Patch status is fused with monitoring. A device that reboots unexpectedly at 2am after an update fires an alert with full context — the deployment window, the KBs installed, the reboot event — instead of a mystery outage discovered by users at 8am. The 2am alert already contains the "why," so the on-call tech triages in seconds instead of running a four-tab correlation session.

2. Deployments are staged and reversible. Schedule patches, stage them by department or device group — pilot ring first, then floor-by-floor rollout, then servers — and roll back the ones that cause issues. A bad KB hits five canary machines, not five hundred.

3. Failures become owned tickets. A failed patch in an integrated platform opens a helpdesk ticket with the device's patch history attached. Nothing re-fails silently for six months, because silence isn't possible when patching, alerting, and the helpdesk share one timeline.

For MSPs, this is the difference between NOC staff living in twelve tabs across five tools per client, and one dashboard where patch posture, alert context, and ticket history sit side by side across every client. When a client calls at 9am asking "did last night's updates break anything?", you answer from one screen, with evidence.

Practical Steps: Verify What Actually Shipped

Before you trust any dashboard — including ours — verify independently. Here are three checks you can run today.

Sweep the fleet for pending reboots. This is the single biggest gap in most patch reports:

$results = foreach ($s in (Get-Content .\servers.txt)) {
    $pending = Invoke-Command -ComputerName $s -ScriptBlock {
        (Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending') -or
        (Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired') -or
        ($null -ne (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager' -Name PendingFileRenameOperations -ErrorAction SilentlyContinue))
    }
    [PSCustomObject]@{ Server = $s; PendingReboot = $pending }
}
$results | Export-Csv .\pending-reboots.csv -NoTypeInformation

Every True in that CSV is a machine your patch dashboard may be calling "compliant" while it still runs the vulnerable binary.

Verify a specific KB actually installed. When an exploit drops and the fix shipped two Patch Tuesdays ago, spot-check instead of trusting the rollup:

$required = 'KB5044284'
Get-HotFix -ComputerName SRV-FS01 |
    Where-Object HotFixID -eq $required |
    Select-Object PSComputerName, HotFixID, InstalledOn

No result means it's not there — whatever the dashboard said.

On Linux hosts, let the package manager tell you the truth:

# Ubuntu/Debian: is a reboot required to activate installed updates?
if [ -f /var/run/reboot-required ]; then
    echo "REBOOT REQUIRED — affected packages:"
    cat /var/run/reboot-required.pkgs
else
    echo "No reboot required"
fi

Then make this continuous instead of manual. In AlertMonitor, the workflow looks like this:

1. Build your rings. A canary group of 5–10 machines, then department rings, then server groups. Stage each deployment through them in order.
2. Treat "pending reboot" as an alertable state. AlertMonitor surfaces it per device in real time, so a stale fleet shows up on a dashboard — not in a vulnerability scan three weeks later.
3. Let the 2am alert carry its context. Unexpected reboot after a deployment window? The alert includes the patch history. On-call sees cause, not mystery.
4. Auto-ticket the failures. A patch that fails twice becomes a helpdesk ticket with the device timeline attached, assigned and tracked like any other work item.
5. Review the patch truth weekly. Missing, failed, and pending-reboot counts per group — fifteen minutes, one screen, numbers you would bet the audit on.

The lesson from this week's Rails-versus-Rust circus isn't about programming languages. It's that whoever runs the demo controls the story — and in patch management, the demo has been writing your compliance report for years. Instrument the outcome, verify the state of every machine, and let your alerting tell you the truth at 2am instead of your users telling you at 8.

Related Resources

AlertMonitor Patch Management & Software Updates AlertMonitor Platform Overview Book a Demo Patch Management & Software Updates Resources