Objective
To explain how Automox handles automatic device reboots following patch policy execution, including how patch success/failure states, reboot flags, and failure prevention logic affect system restarts.
Overview
Automox reboots a device only when an installed update's package manifest explicitly indicates a reboot is required. Even when the policy setting Automatically Reboot After a Patch Policy Runs is enabled, a reboot occurs only if at least one installed update calls for a restart and all targeted updates in that run execute successfully.
Policy Outcome & Reboot Matrix
The table below outlines how installation success states determine whether an automatic reboot triggers at the end of a policy cycle, along with the operational reasoning behind each behavior:
| Patch Execution Result | Reboot Required Flag Status | Policy Outcome / Reboot Action | Reason for Blocking or Executing Reboot |
| All Updates Successful | At least 1 update requires a reboot | Device Reboots | All patches completed cleanly; system reboots to apply and finalize pending changes. |
| All Updates Successful | No updates require a reboot | No Reboot | Expected behavior. No installed package requested a system restart. |
| First-Party Update Failure (e.g., Windows OS/KB) | Any state | Reboot Blocked | Prevents partial OS update states and eliminates unnecessary user disruptions on policies scheduled to run daily. |
| Third-Party Update Failure (e.g., Chrome, Zoom) | Any state | Reboot Blocked | Prevents forcing unnecessary reboots on daily recurring policies when a non-essential application fails to install. |
💡 Best Practice Recommendation:
Split First-Party (OS/Cumulative) updates and Third-Party applications into separate patch policies.
Because Third-Party updates rarely require a system reboot, isolating them prevents a single failing Third-Party app installation from blocking critical OS reboot cycles and finalizing Windows kernel updates. Failed Third-Party updates can then be re-attempted independently without impacting OS patching compliance.
How to Verify Whether a Reboot Was Required
Use any of the following methods to confirm whether installed patches flagged a required restart:
Method 1 — Software Page: Open the Software page in the Automox Console and review the Required Reboot column for the installed updates.
Method 2 — Device Details Page: Open the target device's Device Details page, scroll down to the Software section, and review the Requires Reboot field for applied packages.
Method 3 — API Check: Locate the package names in Reports > Activity Log, then query the
getSoftwarePackagesAPI endpoint (see the Automox Developer Portal). Check therequires_rebootboolean attribute:
{
"packageName": "2026-08 Cumulative Update for Windows 11 (KB5031234)",
"requires_reboot": true
}Troubleshooting Pending or Delayed Reboots
If an update required a reboot but the endpoint did not restart:
Active Hours & Deferrals: Check for Windows Active Hours or end-user notification deferrals. Active deferral windows delay required restarts until the next permitted maintenance window.
Patch Failure Blocking: Check the Activity Log to confirm whether a single package within the policy run returned an installation error.
Escalation: If a package required a reboot, no deferrals are active, all packages succeeded, and the device still fails to restart, contact Automox Support with the device ID and local agent logs (
amagent.log).