Patch Tuesday Is Over. So Why Are 40 Machines Still Missing Updates?

This week The Register profiled TinyJS, a micro JavaScript runtime for building desktop apps that reuses the operating system's built-in webview instead of bundling its own Chromium. A desktop app that would ship at 150–200 MB as an Electron package lands at a few megabytes. The driving idea is one every IT team should steal: every megabyte of software you deploy is a megabyte you have to update, secure, reboot for, and eventually troubleshoot.

Developers are acting on that idea. IT operations mostly aren't. Look at any managed Windows endpoint and count the independent update channels: Windows itself, Office, Edge, Chrome, Adobe Reader, Zoom, the VPN client, 7-Zip, VLC. Patch Tuesday covers the operating system and a slice of Microsoft's stack. Everything else runs on vendor updaters, silent failures, and machines that have been pending a reboot since the second Tuesday of last month.

And in most environments, the true patch state of the fleet is discovered by end users first — via a ticket that says Outlook will not open, three days after a broken update installed.

The Problem in Depth: Your Patch Status Is a Guess, Not a Fact

If you run a legacy RMM, or WSUS plus a spreadsheet, some of these will sting:

• Point-in-time scans. Most patch modules scan every 12–24 hours. A laptop that connects after the scan shows green until the next cycle. Your compliance report is a snapshot, not a state.
• Failure blindness. Patches fail constantly — 0x800f0922 when the component store runs out of room, a corrupted SoftwareDistribution folder, an agent that died mid-install. If your tool logs attempted and moves on, nobody notices until an audit or a user finds it.
• Pending reboot purgatory. The patch is installed, but the servicing stack will not finish until reboot. That file server with 47 days of uptime? Half its updates are not actually applied, and the dashboard says compliant.
• The third-party gap. Windows Update does not touch Chrome, Adobe, Zoom, or anything with a vendor-specific updater — or worse, no updater at all. Year after year, breach reports point to unpatched, frequently third-party software as a leading initial access vector.
• No feedback loop. A scheduled 2am reboot happens, a critical service fails to come back, and nothing tells you. The first signal is ticket #1 at 8:04am. By ticket #14, a technician is reconstructing a timeline from a monitoring tool, an RMM, WSUS, and a helpdesk that share no data.
• Approvals in one place, truth in another. You approve in WSUS, deploy through the RMM, verify by spot-checking machines, and report through exports. Four systems, one fact that lives only on each endpoint.

The business impact is measurable: patch windows that were supposed to end Tuesday night bleed into Thursday cleanup; each failed patch costs 20–40 minutes of a technician's time to diagnose; a reboot outage discovered by users turns a five-minute fix into a half-morning of ticket triage; and when cyber insurance asks whether endpoints are patched within 14 days, the honest answer is mostly.

How AlertMonitor Closes the Loop

AlertMonitor's patch management module is built on a different assumption: patch status is operational data, not a quarterly compliance checkbox.

• Real-time status per device. Missing updates, failed patches, and pending reboots are tracked live for every managed Windows machine — not as of the last scan.
• Staged, scheduled deployments. Push to a pilot ring of IT machines, then department groups, then the fleet, each with its own maintenance window so finance workstations are not rebooting mid-payroll-run.
• Rollback when it goes sideways. A deployment that breaks something can be rolled back instead of hand-remediating 60 endpoints one at a time.
• Patching integrated with monitoring. This is the piece legacy stacks cannot fake: when a device reboots at 2am after a deployment, the alert says so — planned maintenance reboot, KB5044284, window 01:00–03:00. If a service fails to start afterward, you get that alert at 2:01am with full context instead of a mystery outage discovered by users at 8am.
• Patching integrated with helpdesk. A failed patch can open a ticket automatically with the KB number, error code, and device history attached, so whoever picks it up starts at minute five, not minute zero.
• RMM actions where you need them. The classic Windows Update breakage — stuck SoftwareDistribution, corrupt datastore — gets fixed through remote script execution, not a screen-share marathon.

For MSPs, this compounds: per-client patch policies, approval rings, and one NOC dashboard where patch compliance across 50 client environments is a live view instead of a Friday afternoon export project.

The old workflow: scan on Wednesday, export to Excel Thursday, chase machines by email, learn about the 2am outage from users. The AlertMonitor workflow: stage the rings Monday, watch the live status board during the window, get a contextual alert the moment anything reboots or fails, and let a failed patch open its own ticket.

Practical Steps You Can Take Today

Before your next Patch Tuesday, get ground truth. These are the checks that matter most, straight from the trenches.

1. Find your pending-reboot population. These are machines where patches are installed but not actually applied:

$computers = 'SRV-APP-01','SRV-DB-02','PC-FIN-07','PC-HR-12'

Invoke-Command -ComputerName $computers -ScriptBlock {
    $pending = (Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired') -or
               (Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending')

    $os = Get-CimInstance Win32_OperatingSystem
    [PSCustomObject]@{
        Computer      = $env:COMPUTERNAME
        PendingReboot = $pending
        LastBoot      = $os.LastBootUpTime
        UptimeDays    = [math]::Round(((Get-Date) - $os.LastBootUpTime).TotalDays, 1)
    }
} | Sort-Object UptimeDays -Descending | Format-Table -AutoSize

Anything showing PendingReboot True with double-digit uptime is a patch that exists only on paper.

2. List what is actually missing — including on machines your scan window missed:

Install-Module PSWindowsUpdate -Force -Scope CurrentUser
Get-WindowsUpdate -ComputerName PC-FIN-07
Install-WindowsUpdate -ComputerName PC-FIN-07 -AcceptAll -IgnoreReboot

Use -IgnoreReboot so installs stage without a surprise restart — let AlertMonitor's maintenance window control the reboot instead.

3. Check disk space first. Low free space is the most common silent killer of cumulative updates:

Invoke-Command -ComputerName $computers -ScriptBlock {
    Get-CimInstance Win32_LogicalDisk -Filter 'DriveType=3' |
        Select-Object DeviceID,
            @{n='FreeGB';e={[math]::Round($_.FreeSpace/1GB,1)}},
            @{n='FreePct';e={[math]::Round(($_.FreeSpace/$_.Size)*100,1)}}
} | Where-Object { $_.FreePct -lt 15 }

If a machine shows under 15% free on C:, clear space before deployment — otherwise it becomes another 0x800f0922 on next month's exception list.

4. Do the same for your Linux servers:

# Count pending package updates (Debian/Ubuntu)
apt list --upgradable 2>/dev/null | grep -c 'upgradable'

# Check whether the OS is flagging a required reboot
if [ -f /var/run/reboot-required ]; then cat /var/run/reboot-required; else echo 'No reboot required'; fi

5. Then make it continuous. Scripts give you a snapshot; AlertMonitor gives you the state of every device, all the time. Build a Patch-Ring0-IT device group, schedule the deployment with a maintenance window, watch the live status board during rollout, and set an alert policy so any unplanned reboot outside the window pages you with full context — while a failed patch auto-creates a ticket with the KB and error code attached.

The Takeaway

TinyJS is a good reminder that less software is easier software to maintain. You will never get your patch surface to zero — but you can stop guessing at it. When patch status, monitoring, and the helpdesk run on the same data, Patch Tuesday stops being a three-day event and becomes a window you watch from one screen, with alerts that tell you what happened and why before your users do.

Related Resources

AlertMonitor Patch Management & Software Updates

AlertMonitor Platform Overview

Book a Demo

Patch Management & Software Updates Resources