The Register recently profiled Jevstiller, an open-source tool that distills the Jev model so it can run on your own hardware. The architecture deserves every IT operator's attention: Jevstiller targets 98% agreement with its upstream model by handling familiar requests locally, and it sends only uncertain queries upstream — where each one gets audited.
Read that again: handle the familiar automatically. Escalate only what is uncertain. Audit everything.
That is not just good AI engineering. It is exactly the operating model your patch management process should follow — and almost nobody's does. Most IT teams run patching at one of two broken extremes, and both extremes end the same way: either a technician burns a week every month clicking Approve, or an unattended driver update reboots a file server at 2am and the on-call tech gets paged into a mystery outage with zero context.
If you have ever opened a WSUS console at 6am to figure out why a domain controller restarted overnight, this one is for you.
The Problem in Depth: The Two Broken Extremes of Patching
Extreme one: approve everything by hand. An MSP tech managing 40 clients and roughly 2,400 endpoints opens the patch console on Patch Tuesday to a wall of KBs. There is no realistic way to evaluate each one, so what starts as careful review degrades into rubber-stamping by Wednesday. The approval step becomes theater — you have added a human bottleneck without adding human judgment where it actually matters.
Extreme two: auto-approve everything. No approvals means a graphics driver ships to your engineering workstations, or a cumulative update reboots the domain controller during month-end close because nobody defined a maintenance window. Your standalone monitoring tool fires 'host down' at 2:14am. The on-call tech VPNs in at 2:20, finds nothing wrong — the machine came back in four minutes — and at 8am three users file tickets about their computers restarting overnight. Nobody connects the dots, because patching, monitoring, and the helpdesk live in three disconnected tools.
And the middle ground is invisible in both cases. WSUS reports the patch as installed, but the device has sat in a pending-reboot state for 19 days. Until that restart happens, the patch is not actually applied — the machine is unpatched in every way that matters, and it is one surprise reboot away from taking users offline. Meanwhile, your next CIS or HIPAA audit flags exactly these machines, and pulling the evidence takes an afternoon of CSV archaeology.
These gaps exist because the tools were never designed to talk to each other:
- WSUS and MECM hold patch state but have no live monitoring, no alerting context, and no helpdesk integration.
- RMM patch modules run alongside — not inside — monitoring, so a reboot alert never knows it was caused by a patch job.
- Helpdesks never learn that a patch failed, so 'my machine keeps restarting' tickets start from a blank page.
- No audit trail links patch to policy to approval to outcome. Six months later, 'which machines got KB5044284 and who approved it?' is an unanswerable question.
The business cost is concrete: security exposure windows that stretch from days to weeks; 15 to 20 technician hours per week consumed by patch overhead in a mid-size MSP; helpdesk tickets generated by your own patch process; on-call burnout from context-free 2am pages; and SLA reports built on guesses because the monitoring, patching, and ticketing data live in separate systems.
How AlertMonitor Solves This
AlertMonitor's patch management module is built on the same principle as Jevstiller: automate what is known, escalate what is risky, audit all of it.
Real-time patch state for every device. The dashboard shows exactly which managed Windows machines are missing updates, which have failed patches, and which are pending a reboot — across your whole environment, or per client for MSPs. No script sweeps, no exports, no ambiguity about whether a patch actually landed.
Ring-based staged deployment. Define a Pilot group (IT staff machines), a Standard group, and a Sensitive group (servers, execs, regulated systems). Low-risk quality and definition updates auto-advance once they clear the pilot ring — that is your familiar path, handled automatically. Driver updates, feature updates, and anything touching domain controllers, SQL, or Exchange hold for explicit human approval — your escalate-upstream path. Every approval decision is logged with a name and timestamp.
Schedules and maintenance windows. Stagger Patch Tuesday across departments and client sites. Servers patch inside a defined overnight window with the reboot contained; workstations patch during business hours with a deferral prompt. Nobody's whole site reboots at once.
Rollback when a ring goes sideways. If the pilot ring shows failures or post-patch service errors, halt the rollout and roll back before it reaches 500 endpoints.
Monitoring-aware alerts with full context. Because patching lives in the same platform as monitoring, a device that reboots at 2am after an update fires an alert with complete context: which patch job, which KB, start time, completion status, duration. The on-call tech sees 'planned patch reboot — job #4812, success, 4m 12s' instead of a mystery outage discovered by users at 8am. Better still, suppress paging entirely inside the maintenance window and nobody wakes up for a planned event.
Helpdesk integration that closes the loop. A failed patch automatically opens a ticket carrying the device name, KB number, and error code. Your tech starts with data, not questions.
An audit trail that survives the audit. Which machine got which KB, when, under which policy, approved by whom — exportable on demand when compliance comes knocking.
The workflow difference is the difference between twelve tabs across five tools and one dashboard where patch status, live device health, and the ticket queue all reference each other.
Practical Steps You Can Take Today
1. Baseline your reboot backlog
Pending reboot is where patches go to die. Sweep your fleet and see how big your invisible gap is:
$servers = Get-Content .\servers.txt
$results = foreach ($server in $servers) {
$pending = Invoke-Command -ComputerName $server -ScriptBlock {
@(
Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending'
Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired'
) -contains $true
}
[PSCustomObject]@{
Server = $server
RebootPending = $pending
}
}
$results | Sort-Object RebootPending -Descending |
Export-Csv .\pending-reboots.csv -NoTypeInformation
Every machine with a pending-reboot flag is unpatched in practice. In AlertMonitor, those machines are flagged on the patch dashboard continuously — no scheduled script required.
2. See what is actually missing on a problem device
# One-time setup
Install-Module PSWindowsUpdate -Force
# List missing updates on a remote server
Get-WindowsUpdate -ComputerName FS01 -MicrosoftUpdate |
Select-Object KB, Title, Size |
Format-Table -AutoSize
3. Check the Linux side of the house
If your MSP book includes Ubuntu servers, a quick backlog check looks like this:
for host in web01 db01 app01; do
count=$(ssh "$host" "apt list --upgradable 2>/dev/null | grep -c upgradable")
echo "$host: $count update(s) pending"
done
4. Build your rings in AlertMonitor
- Pilot: IT department machines. Auto-approve security and quality updates.
- Standard: general workstations. Auto-approve after 7 clean days in Pilot.
- Sensitive: domain controllers, SQL, Exchange, exec devices. Manual approval, tight maintenance window, rollback on alert.
5. Write down your confidence threshold
Put it in the patch policy where the whole team can see it:
- Auto-approve: monthly cumulative updates, .NET updates, Defender definitions.
- Manual approval: driver updates, feature updates, anything touching line-of-business apps.
- Halt conditions: failure rate above 5% in any ring, or a post-patch critical service alert.
6. Verify the context loop on the next Patch Tuesday
Watch what your on-call actually receives at 2am. If it says 'server down' with no context, you are still running a siloed stack. In AlertMonitor the event reads: 'Device FS01 rebooted as part of patch job #4812 (KB5044284). Completed 02:07, duration 4m 12s.' Planned reboots inside a maintenance window do not page anyone at all.
The Jevstiller project understands something IT operations has known for decades but rarely implemented: pure automation is reckless, pure manual review does not scale, and the only sustainable model is confident automation with human escalation on the edge — and an audit log underneath all of it. Your patch process deserves the same architecture.
Related Resources
AlertMonitor Patch Management & Software Updates AlertMonitor Platform Overview Book a Demo Patch Management & Software Updates Resources
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.