Policy Results Report When Missed Patch Window is Enabled

Issue

A policy configured with the Missed Patch Window option ("If a device misses a configured patch time, it will patch the next time the device checks in") produces Policy Results report entries that do not line up with the policy schedule. Common forms of this confusion:

• A device does not appear in the report at all after the scheduled patch time.
• A device appears in the report hours or days after the scheduled time.
• Several policies show run times clustered together at a time when none of them were scheduled.
• The report timestamp does not match the time configured in the policy schedule.

Environment

• Automox console (current release) — Reports > Policy Results
• Patch policies on any supported OS (Windows, macOS, Linux)
• Policy Schedule settings, including the Missed Patch Window option

Overview

The report only ever reflects what actually ran. Four behaviors explain almost every "the report doesn't match the schedule" question:

• Only devices that started or completed the most recent policy run appear in the report. A device that has not yet run the policy — because it was offline, or because its run is still queued — has no row until it actually executes. Absence from the report is not an error state.
• Missed Patch Window applies only to devices that were offline at the scheduled patch time. With the option enabled, an offline device runs the policy at its next check-in, and its report entry appears at that later time — this is the feature working as designed. See Missed Patch Window for the feature itself. With the option disabled, an offline device simply skips that run and waits for the next scheduled window.
• Online-but-busy devices queue and run late regardless of the Missed Patch Window setting. If a device is online but occupied with another long-running policy or Worklet at the scheduled time, the platform holds the patch command and delivers it when the device frees up. The Missed Patch Window setting is irrelevant in this case — the run was never "missed," only delayed — so a late report entry can appear even on a policy with the option disabled.
• A pending user notification on one policy can lead to several policies running together. When a policy run is held behind a pending install or restart notification, resolving that notification (the user accepts, or the deferral period ends) releases the run — and other policies with pending work on the device can execute at that same time. This produces report rows for multiple policies with near-identical timestamps well outside their individual schedules, and it occurs whether or not the Missed Patch Window option is enabled on those policies.

Separately, watch the timezone: policy schedules are evaluated in the device's local time zone by default, while report and activity timestamps may be displayed in UTC. A run that looks hours early or late can be exactly on schedule once converted.

Resolution

Use these checks to explain a report entry (or a missing one):

1. Open Reports > Policy Results and note the run timestamp for the device and policy in question.
2. Convert the timestamp to the device's local time zone before comparing it to the policy schedule. A consistent offset that matches the device's UTC offset means the run was on schedule.
3. If a device is missing from the report, verify whether it was offline at the scheduled time (check Last Check-in time on the device details page). An offline device with Missed Patch Window enabled runs — and appears in the report — after its next check-in; with the option disabled, it waits for the next scheduled window.
4. If the device was online but the run is late, check whether another policy or Worklet was executing on the device at the scheduled time. Queued runs execute as soon as the device is free; the Missed Patch Window setting does not change this.
5. If several policies ran together at an unscheduled time, check whether any of them uses install or restart notifications. The console does not display when a notification was sent, shown, or accepted on a device, so this moment cannot be observed directly — infer it from the runs themselves: a cluster of near-identical run timestamps typically marks the point the user accepted the notification or the deferral period ended, and the maximum deferral configured on the policy bounds how far past the schedule that can be.
6. If patching must never occur outside a defined window, do not rely on disabling Missed Patch Window to enforce it — a queued or notification-held run can still execute later. Configure an exclusion window instead (see Managing Exclusion Windows). A run prevented by an exclusion window appears as Blocked in the Policy Results Report and is logged as an error in the Activity Log; exclusion-window times are scheduled and displayed in UTC.

Notes

• Missed Patch Window answers exactly one question: "the device was offline at the patch time — should it patch at next check-in, or skip?" It does not govern devices that were online at the scheduled time.
• The report shows execution reality, not schedule intent. A late entry usually means the run itself happened late (offline catch-up, busy device, or notification deferral), not that the report is wrong.