Why Is This Still Using My Computer? Taking Back Patch Control When Every App Updates Itself

Pete Steinberger, creator of the AI assistant OpenClaw, mentioned at Cloudflare Connect that he spent $10 million on AI tokens in a single month. Cloudflare CEO Dane Knecht pointed out that nobody else in the room has a "virtually unlimited token budget." Steinberger's reply is the part worth taping to your monitor: "What people don't always understand is not all of that is useful."

Then he asked the question that should bother every IT team: why is this still using my computer?

If you run IT internally or manage client environments as an MSP, read that question twice. Your end users ask a version of it every time their workstation crawls because an auto-updating agent is burning CPU in the background. And you should be asking it about every endpoint you manage — because modern software installs runtimes, updates itself, schedules reboots, and behaves like it owns the machine. Most patch processes running in production today were never designed for that reality.

Your Patch Surface Is No Longer Windows and Office

Ten years ago, patching meant a WSUS server plus an Office update channel. Both assumptions are dead. Microsoft deprecated WSUS in 2024 — no new features, driver synchronization gone — and the endpoints it was built to manage no longer exist either.

A typical business workstation today runs Chrome, Edge, or Firefox, each on its own release train; Zoom, Teams, and Slack; Adobe Acrobat; 7-Zip; VLC; Notepad++; VS Code; Git. Developers add Node runtimes, Docker Desktop, WSL kernels, and Python. And in the last year a new category appeared: AI agents and local LLM tooling — the OpenClaw-style assistants — that install themselves, auto-update on their own schedule, and register background tasks. Your users install them the way they installed Chrome fifteen years ago: without a ticket.

Windows Update covers Microsoft software. It knows nothing about the 7-Zip Mark-of-the-Web bypass, the Chrome zero-day fixed on a random Tuesday, or last month's Zoom CVE. Industry research has repeated the same finding for a decade: most successful breaches exploit vulnerabilities for which a patch already existed. The gap was never awareness. It is execution and visibility.

Where the Current Toolchain Breaks

The typical mid-size IT shop runs a standalone patch tool bolted onto a ConnectWise- or Ninja-class RMM, a separate monitoring product, and a separate helpdesk. Each piece does its job. Together they fail, in predictable ways:

• The patch console reports activity, not outcomes. "Deployment finished successfully" means the job ran — not that the patch is verified installed on every device. In real environments, 10–20% of machines silently miss any given ring: Windows Update cache corruption, a device asleep during the window, an agent that checked in late.
• Pending reboots are invisible. The patch installed; the user deferred the reboot — for three weeks. The device is still running the vulnerable binary, and nobody has a per-machine view of that state.
• Auto-updaters fight your schedule. Chrome forces a relaunch mid-afternoon. A developer's AI agent updates its Node runtime and quietly breaks an internal build tool. A Zoom update restarts the app during a client call.
• Monitoring does not know about patching. A device reboots at 02:14 and monitoring fires a naked host-unreachable alert. On-call has no way to tell an expected post-patch restart from a dead server — so they either wake the team for a planned reboot or dismiss an alert that turns out to be a real failure.
• The helpdesk finds out first. Users report the dead app Monday at 08:00. Root-cause archaeology follows: RDP to the box, dig through update history, guess.
• Nothing shares state. The patch tool doesn't tell the monitoring system; monitoring doesn't annotate alerts; the helpdesk has no device context. MTTR inflates, and the monthly SLA report gets assembled by hand in Excel from three exports.

Ask any MSP tech about the Wednesday after Patch Tuesday. Sixty clients, jobs ran overnight from the patch tool. Wednesday morning brings 14 tickets across six clients: "Outlook is slow," "can't print," "machine restarted itself." Each one means RDP, Event Viewer, and guesswork. Meanwhile, one machine at an accounting client failed its cumulative update and sat in a reboot loop all night — monitoring flagged it down at 02:14, on-call dismissed it as a false positive because the alert had no context, and the client's bookkeeper found it dead at 08:00. Four hours of client-visible downtime, caused by a patch, discovered by a user, diagnosed by nobody. Every minute of it was preventable with one annotated alert.

The compounding cost is alert fatigue: when most alerts lack context, the real ones get dismissed too. And when patch state lives in one tool, monitoring in a second, and tickets in a third, your MTTR is not a metric — it's a coincidence.

How AlertMonitor Closes the Loop

AlertMonitor's patch management module treats patch state as live telemetry, not a weekly report:

• Real-time status per device. Every managed Windows machine shows whether it is compliant, missing updates, has failed patches (with error codes), or is sitting on a pending reboot. Fleet-wide and per client, filterable in one view.
• Scheduled, staged deployments. Build rings — pilot group, then department, then site, then company — with maintenance windows per group. MSPs get per-client approvals and separate rings per tenant, so one client's payroll server never patches at the same time as another's.
• Rollback that works. If a patch breaks an application, roll it back from the same console instead of rebuilding the machine.
• Monitoring with context. Because patching and monitoring share a data layer, a 02:14 reboot does not fire a naked host-down alert. It fires: host rebooted — triggered by patch deployment #4821, 9 updates installed, restart completed in 4 minutes. And if a device does not come back after its window, that alert names the last KB that was applied.
• Helpdesk wiring. A failed patch can auto-open a ticket pre-filled with device, assigned user, KB number, and error — no swivel-chair, no copy-paste, no lost context.
• RMM actions in place. From the same console, run the compliance scripts below, restart a stuck service, or force the deferred reboot inside the maintenance window.

The old way: patch tool → CSV export → monitoring tool → helpdesk tool. Wednesday is triage day, and nobody can answer "was that reboot ours?" without three console logins.

The AlertMonitor way: Tuesday 22:00, ring 3 deploys. 02:14, the reboot alert arrives annotated — expected. 06:00, the dashboard flags two failed installs and has already opened their tickets. 08:00, one tech resolves both. The Monday standup reviews a single compliance report instead of reconstructing the week from memory.

What You Can Do Today

1. Inventory the self-updating software on your endpoints

You cannot patch what you don't know is installed. This pulls the installed-application list — the same surface where most auto-updaters and user-installed AI agents live:

$paths = @(
  'HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*',
  'HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'
)
Get-ItemProperty $paths -ErrorAction SilentlyContinue |
  Where-Object { $_.DisplayName } |
  Select-Object DisplayName, DisplayVersion, Publisher, InstallDate |
  Sort-Object DisplayName -Unique |
  Export-Csv "$env:PUBLIC\third-party-inventory.csv" -NoTypeInformation

2. Find the machines sitting on a pending reboot

Pending reboots are the most common reason a "successfully deployed" patch is not actually applied. This detects the standard indicators:

$reasons = @()
$cbs = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending'
$wu  = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired'
if (Test-Path $cbs) { $reasons += 'CBS RebootPending' }
if (Test-Path $wu)  { $reasons += 'Windows Update RebootRequired' }
$sm = Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager' -ErrorAction SilentlyContinue
if ($sm.PendingFileRenameOperations) { $reasons += 'PendingFileRenameOperations' }
if ($reasons) { "REBOOT PENDING ($($reasons -join ', '))" } else { 'No reboot pending' }

3. Scan a machine for missing updates on demand

Useful when a user reports a problem or before you approve the next ring:

$session  = New-Object -ComObject Microsoft.Update.Session
$searcher = $session.CreateUpdateSearcher()
$missing  = $searcher.Search("IsInstalled=0 and Type='Software'")
$missing.Updates |
  Select-Object Title,
                @{n='KB'; e={ $_.KBArticleIDs -join ', ' }},
                @{n='Severity'; e={ $_.MsrcSeverity }},
                RebootRequired |
  Format-Table -AutoSize

4. Sweep the server estate before your next patch window

Run the same checks fleet-wide and get one table of what is exposed:

$servers = Get-Content C:\Reports\servers.txt
Invoke-Command -ComputerName $servers -ScriptBlock {
  $cbs = Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending'
  $wu  = Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired'
  [PSCustomObject]@{
    Server        = $env:COMPUTERNAME
    LastPatch     = (Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 1).InstalledOn
    PendingReboot = ($cbs -or $wu)
  }
} | Sort-Object PendingReboot -Descending | Format-Table -AutoSize

5. Don't forget the Linux servers

If your environment — or your clients' — includes Linux, the equivalent check is two lines:

# Does this server need a reboot after patching?
if [ -f /var/run/reboot-required ]; then
  echo "REBOOT REQUIRED: $(cat /var/run/reboot-required.pkgs 2>/dev/null | tr '\n' ' ')"
else
  echo "No reboot required"
fi

# Count outstanding package updates (Debian/Ubuntu)
apt list --upgradable 2>/dev/null | tail -n +2 | wc -l

6. Turn this into an automated workflow in AlertMonitor

• Import or sync your device groups, then define rings and maintenance windows per department, site, or client.
• Create the alert policy: every post-patch reboot is annotated automatically; every failed patch opens a ticket in the right queue with the KB and error attached.
• Put the patch compliance dashboard in front of management monthly. It generates itself — no Excel archaeology.

Steinberger's $10 million admission — "not all of that is useful" — applies to patching too. Running updates is not the same as knowing they landed. The goal for your endpoints is simple: when software reboots a machine at 2am, your answer to "why is this still using my computer?" is "because we scheduled it, it's tracked, and we knew within four minutes that it went fine." That is the entire job. AlertMonitor exists to make that sentence true.

Related Resources

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