Pending Reboot Since March: How Forgotten Patch State Turns Endpoints Into Public Outages

Late September, The Register published a story about the flight information displays at Heathrow showing what the author called 'eldritch horror' — corrupted, glitching, half-rendered screens greeting international passengers at one of the busiest airports on the planet. A triptych of broken displays, each failing differently, in front of thousands of travelers with phones out, taking pictures.

Here's the detail that should make every sysadmin squirm: those screens were almost certainly online. Something was pinging them. A monitoring console somewhere very likely showed green. Nobody was watching whether the content was actually rendering — and nobody had a clean answer for what patch state the underlying device was in.

That is not an airport problem. That is a patch verification problem, and you have the same class of devices in your environment right now.

Every Network Has a Heathrow Screen

Think about the endpoints in your estate that fall outside the standard desktop build:

• Digital signage players (frequently Windows 10/11 IoT Enterprise)
• Kiosk and check-in terminals
• Meeting room panels and lobby displays
• That utility server in the comms room that 'nobody touches'
• Warehouse scanners and shop-floor terminals

They get excluded from the desktop imaging pipeline. They sit outside the standard patch ring. Sometimes they're even excluded from monitoring because 'they just display stuff.' And because no single person owns them, they drift.

Then Patch Tuesday happens, and one of four things goes wrong:

1. The install succeeds but the reboot is deferred forever. Someone set the 'No auto-restart with logged on users' GPO, the kiosk profile never logs off, and the device sits with a Component Based Servicing RebootPending key for months. The patch is deployed. It is not applied.
2. The vendor app auto-updates and collides with the OS patch. The signage player updates itself mid-cycle, a .NET or graphics driver update lands underneath it, and the player corrupts. The OS is patched; the application is wreckage.
3. The disk fills with patch residue. pending.xml, WinSxS buildup, failed installs retrying in a loop. The install fails silently every month and the RMM marks it 'attempted.'
4. The reboot happens at 2am and breaks something downstream — and nobody connects the outage to the patch until a human does archaeology in the event logs at 8am.

In audits I run for mid-size IT teams and MSPs, it is common to find 10–20% of Windows devices sitting in a pending-reboot state older than 30 days. The compliance report says 98% deployed. 'Deployed' is doing a lot of heavy lifting in that sentence.

What Your Current Tooling Is Getting Wrong

WSUS and ConfigMgr report deployment state, not outcome state. 'Installed' frequently means 'queued for a reboot that policy keeps deferring.' The approval pipeline is green; the device is not actually running the update.

Ping-and-port monitoring tells you the device is reachable, not that it is healthy. The signage box answers ICMP. The player process is a corrupted zombie rendering nothing. Green on the dashboard, horror on the wall.

Standalone helpdesks make your users the detection layer. The ticket 'the screen in departures is showing garbage' arrives at 09:15. Your real incident start time was somewhere last week. Your MTTR — and your SLA report — are fiction, because the clock the helpdesk measured started when a passenger complained, not when the patch failed.

Bolted-together RMM stacks give you two consoles and two truths. The patch module says one thing, the monitoring tool says another, and nothing correlates 'this device restarted at 02:13' with 'KB5044284 was installing at 02:10.' Your on-call tech gets a mystery instead of a diagnosis. Multiply that across a dozen clients and you get the twelve-tabs-open, five-tools-deep MSP technician who burns the first 20 minutes of every incident just establishing ground truth.

These gaps exist because patching, monitoring, and ticketing were built as separate products and stitched together with connectors. Integration after the fact moves data between systems, but it does not carry context.

How AlertMonitor Closes the Loop

AlertMonitor treats patch state as live operational data, not a monthly compliance export:

• Real-time patch status per device. Every managed Windows endpoint shows exactly where it stands: missing updates, failed installs, and — critically — pending reboot as a first-class state you can report on and act on. No more registry spelunking across the fleet to guess what actually took effect.
• Scheduled, staged deployments. Ring by department, site, or device group. Put your kiosks and signage players in their own ring with a two-unit canary and a 48-hour soak before anything touches the wider estate.
• Rollback when a patch breaks an app. If an update corrupts the signage player, you restore instead of hand-rebuilding a kiosk over remote assist at 11pm.
• Patch-aware monitoring. Because patching is integrated with monitoring, an unexpected 2am reboot fires an alert that says 'device restarted following update install' with the KB and the window attached. On-call you knows in 90 seconds whether that was a patch cycle or a power fault. Users never become your detection layer.
• Post-patch verification. Run a check after the reboot — is the player service running, is the process healthy — and if it fails, the deployment is flagged and a ticket opens with the patch context already attached.
• Helpdesk on the same data. The ticket about the broken screen carries the device's patch history, last reboot, and recent alert timeline. Diagnosis starts at minute one, not minute twenty.

The workflow shift is simple: instead of approve → hope → find out from a user, it becomes approve → deploy to ring → verify service state → alert or roll back automatically.

Practical Steps You Can Take Today

1. Find every device sitting on a pending reboot

$servers = Get-Content "C:\Audit\servers.txt"

$report = foreach ($srv in $servers) {
    $state = Invoke-Command -ComputerName $srv -ScriptBlock {
        [PSCustomObject]@{
            CBSRebootPending  = Test-Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending"
            WURebootPending   = Test-Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired"
            PendingFileRename = Test-Path "$env:SystemRoot\WinSxS\pending.xml"
        }
    } -ErrorAction SilentlyContinue

    if ($state) {
        [PSCustomObject]@{
            Computer      = $srv
            CBS           = $state.CBSRebootPending
            WindowsUpdate = $state.WURebootPending
            FileRename    = $state.PendingFileRename
            NeedsReboot   = ($state.CBSRebootPending -or $state.WURebootPending -or $state.PendingFileRename)
        }
    }
}

$report | Sort-Object NeedsReboot -Descending | Format-Table -AutoSize
$report | Export-Csv "C:\Audit\PendingReboots.csv" -NoTypeInformation

Every True in that output is an update you already paid for — bandwidth, downtime window, change approval — that has not actually taken effect.

2. Find devices whose patch history has gone cold

$cutoff = (Get-Date).AddDays(-60)

Get-ADComputer -Filter "OperatingSystem -like '*Windows Server*'" -Properties DNSHostName |
    ForEach-Object {
        $last = Get-HotFix -ComputerName $_.DNSHostName -ErrorAction SilentlyContinue |
            Sort-Object InstalledOn -Descending |
            Select-Object -First 1
        if ($last -and $last.InstalledOn -lt $cutoff) {
            [PSCustomObject]@{
                Computer  = $_.DNSHostName
                LastKB    = $last.HotFixID
                LastPatch = $last.InstalledOn
            }
        }
    } | Sort-Object LastPatch | Format-Table -AutoSize

Anything that comes back empty or older than your cutoff has silently dropped out of the patch cycle — which is exactly how a Heathrow screen happens.

3. Verify the application survived the patch, not just the OS

$service = "SignagePlayer"

if ((Get-Service -Name $service).Status -ne "Running") {
    Restart-Service -Name $service -Force
    Start-Sleep -Seconds 20

    if ((Get-Service -Name $service).Status -eq "Running") {
        Write-Output "$service recovered after patch cycle."
    }
    else {
        Write-Warning "$service failed to restart — needs manual review."
        # In AlertMonitor this runs as a post-patch verification script;
        # a failure raises an alert and opens a ticket automatically.
    }
}

Wrap this pattern around every fragile workload in your estate — signage players, print servers, line-of-business services. The OS being patched is not the outcome. The workload running is the outcome.

4. Audit your non-Windows players too

for host in $(cat signage_hosts.txt); do
  lastboot=$(ssh -o ConnectTimeout=5 admin@"$host" "uptime -s" 2>/dev/null)
  printf "%-22s last boot: %s\n" "$host" "${lastboot:-UNREACHABLE}"
done

A media box that has not rebooted in 400 days is carrying 400 days of unapplied kernel updates, whatever the vendor console claims.

5. Rebuild your rings in AlertMonitor

1. Create device groups for the forgotten classes: signage, kiosks, utility servers.
2. Deploy to a canary of one or two devices, soak 48 hours, then roll site by site.
3. Attach the post-reboot service check from step 3 to every deployment.
4. Enable rollback on anything with a vendor app that has burned you before.
5. Turn on unexpected-reboot alerting, so an out-of-window restart pages on-call with the device's recent patch activity attached.

The Bottom Line

Heathrow's haunted screens are funny from a safe distance. They are considerably less funny when the screen is your hospital's bed board, your factory's andon display, or a client's lobby wall — and the postmortem reveals a pending reboot from March that four separate tools each saw a fragment of, and none of them connected.

Patch 'deployed' is not patch 'applied,' and patch 'applied' is not patch 'verified.' Getting to verified requires one system where patch state, uptime, application health, and tickets live together — which is precisely the problem AlertMonitor was built to end. Run the pending-reboot audit above this week. You will find your own screens of horror before your users do.

Related Resources

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