Monthly Patch Policy Skipped the Current Month's Cumulative Update (Patch Age Filter Timing)

Issue

A monthly Windows patch policy runs on schedule, but the current month's cumulative update (CU) or monthly security update is not installed. Devices report Remediation Not Applicable or Device Compliant for the run, and the missing update then installs on the next monthly run — roughly a month late. This commonly affects policies that combine a patch age filter (for example, "only apply patches older than 10 days") with a monthly schedule anchored near Patch Tuesday (for example, the fourth Friday of the month).

Environment

• Automox (current agent release)
• Windows patch policies (Windows Update / cumulative updates)
• Console areas: Manage > Policies (patch policy filters and scheduling), Devices (device patch view), Activity Log

Overview

Two independent settings decide whether a given update installs during a policy run:

• The schedule decides when the policy runs. This can be a calendar schedule (for example, the fourth Friday at 4:00 AM) or a schedule anchored to Patch Tuesday plus an offset (for example, "Patch Tuesday + 8 days").
• The patch age filter decides which patches are eligible at that moment. A patch that is younger than the threshold at run time is silently excluded from that run — it is not failed, deferred, or retried; it simply is not scheduled. The policy can still report the device as compliant because nothing eligible was pending.

These two settings do not know about each other. If the policy runs before the month's cumulative update is old enough to pass the age filter, the CU is withheld for that run and waits until the next scheduled run — by which time the next month's CU has usually superseded it.

Two details make this trap easy to fall into:

1. Patch Tuesday moves. It is the second Tuesday of the month, which can fall anywhere from the 8th to the 14th. The gap between Patch Tuesday and a "fourth Friday" run is therefore not constant: depending on how the month lays out, it is either 17 days (comfortable) or only 10 days (tight). A threshold that works most months fails in the tight months.
2. Age appears to be measured to the hour, not in calendar days. In an observed case, a policy ran on the fourth Friday exactly 10 calendar days after Patch Tuesday with a 10-day age filter — and the cumulative update was still excluded, because the update had been detected on the device roughly 9 days and 7 hours before the run. If the measured age has not fully reached the threshold at the run's start time, the patch does not qualify. (Age also cannot start accruing before the device actually detects the update, which happens at the first scan after Microsoft publishes it.)

Worked example

• Patch Tuesday falls on the 14th (its latest possible date). Microsoft releases the monthly cumulative update that day; the device detects it during its next scan, that evening.
• The policy is scheduled for the fourth Friday, 4:00 AM, which in this month is the 24th — 10 calendar days later.
• The policy has a 10-day patch age filter.
• At 4:00 AM on the 24th, the CU's measured age is about 9 days, 7 hours — under the threshold. The CU is excluded, the device evaluates as having nothing to install, and the console shows Remediation Not Applicable.
• The CU does not install until the next monthly run, about four weeks later.

The key signature of this condition: during the window between Patch Tuesday and the run, the cumulative update is visible on the device as an available/pending patch — Automox saw it — but it is not in the set the policy scheduled for installation. If the update is not visible on the device at all, the cause is different (see Notes).

Resolution

Align the age threshold with the worst-case gap between Patch Tuesday and your run time.

1. Open Manage > Policies, select the patch policy, and note two values: the schedule (which day it runs) and the patch age filter threshold (in the policy's filter settings).
2. Work out the minimum possible gap between Patch Tuesday and your run day. Patch Tuesday falls between the 8th and the 14th. For common monthly anchors:
   • Fourth Friday: the gap is 17 days in some months but only 10 days in months where the 1st falls on a Wednesday, Thursday, or Friday.
   • Third Friday or earlier: the gap can shrink to just 3 days in tight months — a patch age filter of more than 1–2 days will regularly skip the CU.
   • Any other anchor: check a calendar for a month where Patch Tuesday lands on the 14th and count the days to your run.
3. Set the patch age threshold to at least 2 full days less than that minimum gap. The buffer covers hour-level age measurement plus the scan delay before the device first detects the update. For a fourth-Friday schedule (minimum gap 10 days), a threshold of 7 days or less keeps the current month's CU eligible every month. This exact change (10 days down to 7) resolved the observed case.

Alternatively, anchor the schedule to Patch Tuesday directly. 

1. Scheduling the policy as Patch Tuesday + N days fixes the gap so it no longer varies month to month. If you also keep a patch age filter, set the threshold below the offset (for example, offset 8 days with an age filter of 7 days or less) — the offset controls when the run happens, the age filter still independently controls eligibility at that moment.

• Verify eligibility on a device before the run. In the window between Patch Tuesday and the scheduled run, open the device in Devices and compare the device's full list of available patches against what is actually scheduled for the next run (the Total vs Scheduled patch views on the device). If the cumulative update appears as available but is not scheduled, a policy filter — patch age being the most common — is withholding it.
• Confirm after the run. Check the Activity Log for the policy run. Remediation Not Applicable with the CU still showing as available on the device indicates the update was filtered out again; re-check the age math. Remediation Not Applicable with no pending OS updates on the device means the device is simply up to date, which is the correct, healthy outcome.

Notes

• Remediation Not Applicable is not an error. It means the policy evaluated the device and found nothing eligible to install for that policy's filters at that moment. That can mean the device is fully patched — or that a filter (patch age, severity, include/exclude rules) excluded everything that was pending. Always distinguish the two by checking whether the update is visible on the device as available.
• If the cumulative update is not visible on the device at all, the patch age filter is not the cause — Automox can only act on updates the Windows Update Agent reports as applicable. Common causes include a WSUS/SCCM-managed update source, a pending feature upgrade blocking cumulative updates, or a stuck Windows Update service. See "Why an Expected Update is Not Available or Missing from a Device" (https://help.automox.com/hc/en-us/articles/31578006436756).
• One skipped month compounds: because monthly CUs are cumulative, the device typically catches up in a single successful run once the filter and schedule are aligned — but it spends the intervening weeks missing the current security baseline.
• If updates appear to install earlier than a Patch Tuesday + offset schedule should allow, verify that no other patch policy targeting the same devices runs sooner, and re-confirm the policy's saved schedule settings.