Windows
View all Worklets
WindowsWindows

Windows - Data Collection & Auditing - Check Battery Health

Audit Windows laptop battery health and capacity metrics to surface degraded batteries before they fail

Worklet Details

What the Windows battery health audit Worklet does

This Automox Worklet™ runs a battery diagnostic on Windows laptops and mobile endpoints, then writes a structured report into the Automox Activity Log. The Worklet uses Get-CimInstance against the Win32_Battery class to enumerate every battery present on the endpoint, including secondary batteries in dual-battery laptops, and reports each one in its own labeled block.

The report covers three sections per battery. Battery Details lists Caption, Description, and Device ID. Battery Health lists Availability, Battery Status, Battery Health Status (the WMI Status property), Battery Health Percentage (FullChargeCapacity divided by DesignCapacity, multiplied by 100), Time on Battery in seconds, Estimated Run Time in minutes, and Estimated Charge Remaining. Battery Specifications lists Battery Type (Chemistry), Design Capacity in mWh, Full Charge Capacity in mWh, Design Voltage in mV, Expected Life in months, and Cycle Count.

Integer return codes from Win32_Battery are translated to readable labels before they reach the Activity Log. BatteryStatus 3 becomes Fully Charged; Chemistry 6 becomes Lithium-ion; Availability 10 becomes Degraded. Indeterminate EstimatedRunTime values (the 71582788 sentinel Microsoft returns during charging) are replaced with a charging-state explanation. The result is a report a support engineer can read directly, with no manual lookup against MSDN tables.

Why audit laptop battery health centrally

Battery degradation is the most common hardware failure in a remote workforce, and it almost always surfaces as a user complaint rather than a managed alert. A laptop drops to two-hour runtime, the user blames Windows Update, and the ticket bounces around until someone runs powercfg /batteryreport on the affected endpoint. By then the user has already missed work or ordered a replacement at retail price.

Refresh-cycle planning normally starts from a half-populated spreadsheet that asks each user to check About This PC and report battery age, and the response rate is rarely above 40%. Schedule this read-only Worklet against the laptop endpoint group so Win32_Battery, EstimatedChargeRemaining, and DesignCapacity values are pulled directly from WMI on every endpoint. The next hardware refresh meeting starts with current per-endpoint cycle and capacity data instead of self-reported estimates, and the output lands in the Activity Log for export into asset planning systems alongside warranty status.

How the battery health check works

  1. Evaluation phase: Reads Win32_ComputerSystem.PCSystemType. If the value is not 2 (Mobile Device), the endpoint is not a laptop and the script exits 0 without flagging. Desktops and servers are filtered out at this stage so policy runtime is not spent on hardware classes that cannot have a battery. Laptops and mobile endpoints are flagged for remediation and the script exits 1.

  2. Remediation phase: Re-confirms the endpoint type, then queries Win32_Battery. If no battery is present (undocked tablet, removed pack), the script logs the condition and exits 0. For each battery detected, the Get-BatteryStatus function extracts the property set, translates the integer enums into readable labels, and writes the three-section report to standard output. The report appears verbatim in the Automox Activity Log for the policy run.

Battery health audit requirements

  • Windows 7, Windows 8, Windows 10, or Windows 11 endpoint classified as a laptop or mobile device (PCSystemType 2)

  • PowerShell v3 or higher

  • Local administrator or SYSTEM context to query Win32_Battery (the Automox agent runs at this level by default)

  • A working battery; an undocked tablet or laptop with the pack removed reports no battery and exits cleanly

  • Some endpoints may require an up-to-date BIOS or firmware revision to populate every Win32_Battery field; unknown values surface as Unknown rather than failing the report

Expected battery diagnostic output

After the Worklet runs, the Activity Log contains one BEGIN BATTERY N DIAGNOSTIC REPORT block per battery present on the endpoint. The most actionable lines for a refresh decision are Battery Health Percentage and Cycle Count. A health percentage below 80 paired with a cycle count above 500 is the industry signal for a battery near end-of-life. The Estimated Run Time line confirms what the user would see at the OS level.

To validate the Worklet on a pilot endpoint, run powercfg /batteryreport from an elevated Command Prompt and compare the generated HTML report against the Activity Log output. The DesignCapacity, FullChargeCapacity, and CycleCount values should match between the two sources. Schedule the Worklet quarterly to feed a refresh-planning dashboard, or run it on demand against a single endpoint when a user reports degraded runtime.

View in app
evalutation image
remediation image

Consider Worklets your easy button

What's a Worklet?

A Worklet is an automation script, written in Bash or PowerShell, designed for seamless execution on endpoints – at scale – within the Automox platform. Worklets deploy named-CVE mitigations within hours of disclosure, perform configuration, remediation, and install or remove applications and settings across Windows, macOS, and Linux.

do more with worklets