A Windows battery report might suggest five hours of battery life, while a coding session lasts closer to two. That difference does not, by itself, prove that the battery is faulty.
The useful distinction is stored energy versus power demand. Battery capacity describes one side of that relationship. Your workload determines the other.
I run Battery Health Lab. This walkthrough focuses on interpreting the estimates table, not selling a replacement battery or treating one number as a diagnosis.
Generate a fresh report
Open PowerShell in Windows Terminal as administrator and run:
powercfg /batteryreport /output "$env:USERPROFILE\battery-report.html"
Open the HTML file at the location printed by the command, then find Battery life estimates near the bottom. This example uses PowerShell environment-variable syntax; it is not a Command Prompt command.
Microsoft documents the report and its output options in the powercfg reference.
Read the column before reading the hours
For active work, start with At full charge → Active. It is a projection using the battery's currently reported full-charge capacity.
At design capacity → Active is a reference comparison using the original design capacity. It is not extra runtime that the current battery can unlock with a setting.
If the table includes Connected Standby, keep it separate from Active. Standby hours and screen-on working hours describe different conditions.
Microsoft's energy-efficiency guidance explains that the battery-life estimate uses the PC's recorded history. The practical implication: a history dominated by light work is not a reliable promise for tomorrow's heavy build or video call.
A simple example: the same battery, two runtimes
Consider these illustrative values, not measurements from a particular laptop:
- Design capacity: 60 Wh
- Reported full-charge capacity: 48 Wh
- Reported capacity ratio: 48 ÷ 60 × 100 = 80%
A simplified energy calculation is:
Runtime in hours ≈ usable energy in Wh ÷ average power in W
48 Wh ÷ 12 W = 4 hours
48 Wh ÷ 24 W = 2 hours
Doubling demand halves the idealized runtime, even though the capacity ratio stays at 80%.
At the same 12 W demand, 60 Wh would imply five hours. That illustrates the idea behind comparing current and design capacity—not a claim that Windows uses this exact calculation for every table entry.
Real systems have changing loads, reporting uncertainty and shutdown reserves, so these calculations are a mental model, not a benchmark. They also assume a full battery; remaining runtime at a partial charge is a different question.
Compare like with like
For a useful check, choose a repeatable slice of your normal work:
- Record the starting charge level and time after unplugging.
- Keep brightness, power mode and connected peripherals consistent.
- Note what ran: editing files, compiling, containers, meetings or something else.
- Record the ending charge level and elapsed time.
- Repeat under comparable conditions, then compare the pattern with a fresh report.
Do not compare an idle reading session with a full rebuild and call the difference battery degradation. Record whether the laptop stayed awake, too; a session containing sleep is not a clean active-use comparison.
There is no need to drain the battery to zero for this exercise. Microsoft advises avoiding frequent deep discharges in its battery-care guidance.
What about blank estimates?
A dash is missing information, not a measured runtime of zero. Check whether the report contains useful discharge history and whether the relevant power state applies to the machine. Collect normal unplugged-use sessions before drawing conclusions from an empty table.
For the individual columns, blank entries and the long-term summary, I wrote a more detailed Windows battery life estimates guide on Battery Health Lab.
Bottom line: use capacity history to investigate reported wear, and repeatable workloads to investigate runtime. The estimate is a clue about past use—not a guarantee about your next charge.
What changes your laptop's unplugged runtime most: builds, video calls, or something running in the background?
Top comments (0)