Files
windows_exporter/docs/runbooks/windowsupdatespending.md
T
Jan-Otto Kröpke d819362150 mixin: add alerts for the opt-in collectors
Every optional collector of the mixin now has alerts, generated only with
that collector enabled in _config.collectors: clock source, disk drive
status, page file usage, license status, scheduled task results, pending
updates, Hyper-V WMI and replication health, failover cluster nodes,
resources, groups and shared volumes, Storage Spaces pool and virtual disk
health, DHCP scope exhaustion and DNS zone transfer failures. The alerts
of the pagefile, diskdrive and license collectors join the memory, disk
and system groups; the other collectors get a group of their own.

New knobs: taskSelector, sharedVolumeSelector, pagefileUsageThreshold,
dhcpScopeFreeWarningThreshold, dhcpScopeFreeCriticalThreshold and
updatePendingDuration. The test configuration enables every optional
collector and tests/optional.test.yaml covers the new alerts.

Signed-off-by: Jan-Otto Kröpke <mail@jkroepke.de>
2026-10-17 02:28:35 +00:00

51 lines
2.0 KiB
Markdown

---
title: WindowsUpdatesPending
---
## Meaning
The host has updates waiting for installation for longer than
`updatePendingDuration`, seven days by default. The alert is an info alert, its
value is the number of pending updates, and it needs the `update` collector,
which queries the Windows Update agent in the background at the interval of
its scrape setting. Updates waiting for uninstallation do not count. Prometheus counts the
duration and restores it after a restart shorter than its
`--rules.alert.for-outage-tolerance`, one hour by default; a longer outage or
a new server starts the wait again.
## Impact
Security updates that wait longer than the patch window leave known
vulnerabilities open. Other updates carry fixes for reliability problems. The
host may also be waiting for a restart to finish an installation.
## Diagnosis
1. List the pending updates with their category and severity:
```promql
windows_update_pending_info{job="windows_exporter", instance="<instance>", deployment_action="installation"}
```
`windows_update_pending_published_timestamp` shows how old each update is.
2. On the host, check the update client and the last installation attempts:
```powershell
Get-WindowsUpdateLog
Get-WinEvent -LogName Microsoft-Windows-WindowsUpdateClient/Operational -MaxEvents 50
Get-CimInstance -Namespace root/cimv2 -ClassName Win32_QuickFixEngineering | Sort-Object InstalledOn -Descending | Select-Object -First 5
```
3. Check whether the host is in a maintenance window, a deferral period or a
WSUS or Configuration Manager deployment that has not approved the updates
yet, and whether a pending restart blocks the installation.
## Mitigation
Install the updates in the next maintenance window, or approve them in the
update management tool. Restart the host if an installation waits for it.
Raise `updatePendingDuration` to the patch window of the environment if seven
days is shorter than the policy, or turn the alert off with
`alerts+: { WindowsUpdatesPending: false }` where another system tracks patch
compliance.