Get Reboot History

What the Windows reboot history reporter does

This Automox Worklet™ queries the Windows System event log on each endpoint and returns the five most recent reboot or shutdown events recorded by USER32. Each event row in the activity log reports the timestamp, the user account that initiated the restart, and the reboot reason text drawn from event ID 1074.

The script calls Get-WinEvent with -FilterHashtable @{logname='System'; id=1074} and pipes each match through ForEach-Object, where the EventData payload is unpacked into a PSObject with named fields: Date, User, Action, Process, Reason, ReasonCode, and Comment. The pipeline ends with Select-Object Date, Reason, User -First $numReboots, so the activity log table renders three columns by default. The $numReboots variable at the top of the remediation script controls the record count (default 5), and the inline comment on the final Select-Object line documents how to project additional fields when you need them.

Event ID 1074 captures user-initiated, system-initiated, and update-initiated restarts, so the same Worklet covers planned maintenance reboots, Automox patch-triggered reboots, admin-driven Restart-Computer calls, and remote shutdown commands. Crash-driven restarts logged under event ID 6008 (unexpected shutdown) and kernel-power event ID 41 (dirty restart) are not pulled by the default filter; both are noted in the validation section below for operators who want to extend the query.

Why audit reboot history across the fleet

Reboot evidence is a frequent gap in patch reporting. A patch policy can mark a CVE remediated while an endpoint keeps running the vulnerable kernel module until the next restart, and a single deferred reboot in a workstation pool can keep a known exploit live for weeks. Auditing the System event log for event ID 1074 gives you the actual restart timestamp tied to the user that triggered it, which is the evidence security and compliance teams ask for when reviewing a patch window.

Schedule this Worklet after a maintenance window and the activity log records reboot history across the fleet in one pass, with no per-endpoint RDP session or help-desk ticket required. Pair it with a follow-on remediation Worklet such as a forced restart or deferred-reboot reset when the audit surfaces endpoints that did not reboot on schedule.

How reboot event collection works

1. Evaluation phase: The evaluation script returns Exit 1 unconditionally, which marks every endpoint as non-compliant on each policy run. That intentionally hands control to the remediation script so the reporting query executes on every endpoint in scope every time the policy fires, instead of caching a prior result.

2. Remediation phase: The remediation script calls Get-WinEvent -FilterHashtable @{logname='System'; id=1074} and pipes each match through ForEach-Object, where Properties[6], [0], [4], [2], [3], and [5] are projected into a PSObject as User, Process, Action, Reason, ReasonCode, and Comment, with TimeCreated assigned to Date. The pipeline ends with Select-Object Date, Reason, User -First $numReboots, so the activity log displays three columns by default. No state-changing action is taken on the endpoint.

Reboot history collection requirements

• Windows 7, Windows 10, Windows 11, or Windows Server 2012 R2 and later with the System event log enabled (the default on every supported Windows build)

• PowerShell 3.0 or higher (Get-WinEvent ships with PowerShell 2.0 but the script uses parameter binding that requires 3.0+)

• Read access to the System event log; the Automox agent runs as SYSTEM and meets this by default

• Optional: change the $numReboots variable at the top of the script to return more than five records (useful when investigating a multi-day restart loop or building a quarterly uptime audit)

• Optional: extend the XPath filter to include event ID 6008 (unexpected shutdown) and event ID 41 (kernel-power, dirty restart) when you also need to surface crashes alongside graceful reboots

Expected reboot history report output

The activity log for a successful run shows a table with three columns by default: Date, Reason, and User. To project additional fields (Action, Process, ReasonCode, Comment), edit the final Select-Object line in the remediation script as noted in the inline comment. Reason text values that appear frequently in fleet reboot reports include Operating System: Service pack (Planned), Operating System: Upgrade (Planned), Power Failure: Cord Unplugged (Unplanned), and a blank reason, which typically indicates a Restart-Computer call without a -Reason parameter.

To validate on a representative endpoint, run Get-WinEvent -FilterHashtable @{LogName='System'; Id=1074} -MaxEvents 5 directly and confirm the row count and timestamps match the Worklet output. For deeper investigation, compare Get-CimInstance Win32_OperatingSystem | Select-Object LastBootUpTime with the most recent Date in the report; the two values should agree within the boot duration of the endpoint. Endpoints that return zero rows have either cleared the System log, restricted access to it, or have never rebooted since installation – each is worth a targeted follow-up, and each becomes visible in one pass instead of one help-desk ticket per host.