macOS has told us our MacBook Pro’s battery is at 100% every time we have looked. We logged the underlying number instead, once a week for twenty days. It read 98.71%, then 98.51%, then 98.22%, then 99.22%, then 97.54%. A battery cannot recover 1 percentage point of capacity in a week, which means at least one of those readings is wrong — and we cannot tell you which.
The usual version of this story is that Apple hides the real number behind a rounded one. We went looking for that story and found something less satisfying and more useful: the number being rounded is noisier than the thing it is supposed to measure.
Where the real number comes from
The Battery Health screen in System Settings shows “Maximum Capacity” as a whole percentage. Underneath, macOS tracks two values in AppleSmartBattery: DesignCapacity, the capacity the battery shipped with, and FullChargeCapacity, the system’s current estimate of what it can actually hold. Divide one by the other and you get a figure with decimals.
You can read it yourself:
ioreg -r -c AppleSmartBattery | grep -E "DesignCapacity|FullChargeCapacity|CycleCount"
We automated that on a weekly schedule rather than checking by hand, which matters — the point of this article is a pattern you cannot see from a single reading.
Twenty days of readings
MacBook Pro 16-inch, M5 Pro, Mac17,8, running macOS 27.0.1. Design capacity 8,579 mAh, unchanged throughout.
| Date | Cycles | Full charge (mAh) | Computed health | What macOS displayed |
|---|---|---|---|---|
| 24 Sep 2026 | 9 | 8,468 | 98.71% | 100% |
| 28 Sep 2026 | 10 | 8,451 | 98.51% | 100% |
| 5 Oct 2026 | 13 | 8,426 | 98.22% | 100% |
| 12 Oct 2026 | 15 | 8,512 | 99.22% | 100% |
| 15 Oct 2026 | 17 | 8,368 | 97.54% | 100% |
Week over week, the computed figure moved -0.20, -0.29, +1.00, and -1.68 percentage points.
The fourth row is the one to look at. Between 5 October and 12 October the battery’s reported full-charge capacity rose by 86 mAh. Lithium-ion cells do not regain capacity. What rose was not the battery but macOS’s estimate of it.
The noise is bigger than the signal
Over the whole twenty days the computed health fell 1.17 percentage points, from 98.71% to 97.54%. The largest single week-to-week movement was 1.68 percentage points.
The week-to-week wobble is larger than the entire twenty-day change. That is the finding, and it has a direct consequence: at this timescale, on this machine, the measurement cannot distinguish real degradation from its own error. If you check this number weekly and watch it drop, you have not learned that your battery is dying. If you check it and watch it rise, you have not learned that it is healing.
We set the bar before looking, the same way we set a noise floor before comparing benchmark results: a change only counts as real if it exceeds the spread we observe when nothing meaningful should have changed. Eight charge cycles over twenty days on a nearly-new battery is close to nothing meaningful. The spread we observed across that period was 1.68 points. So 1.68 points is the floor, and nothing we measured clears it.
So macOS showing 100% is arguably the honest choice
This is where we ended up disagreeing with the framing we started with.
Rounding 97.54% up to 100% looks like concealment. But a display that tracked the raw figure would have shown this user four different numbers in twenty days, including one week where the battery appeared to improve. That would generate exactly the anxiety the number was meant to resolve, over movement that is measurement error.
Apple’s threshold behaviour — hold at 100% until the estimate has moved enough to mean something — is a reasonable response to a noisy sensor. We would prefer it were documented rather than inferred, and we would prefer the raw value were visible for people who want it. It is, in ioreg, which is how we got here.
What we will not claim is that the rounded number is hiding a problem. On this machine, at seventeen cycles, there is no problem to hide.
What we have not established
We cannot give you a degradation rate. Five readings is enough to characterise scatter and not enough to fit a trend. Any “percent per cycle” figure derived from this data would be an artefact of which two points you picked.
We did not control charge level. The readings were taken at 59%, 15%, 23%, 54% and 95% state of charge, with the machine charging in two of them. Full-charge-capacity estimates are known to be influenced by recent charge and discharge history. We looked for a relationship between charge level and computed health across our five points and did not find a clean one — but five points cannot rule it out, and we are not going to present the absence of a pattern in five samples as evidence there is none.
This is one battery. We do not know whether a 1.68-point spread is typical, generous, or unusually tight. A different Mac, an older cell, or a different macOS version could behave differently.
We did not test capacity directly. Everything above is macOS’s estimate. We did not run the battery from full to empty under controlled load and measure delivered energy, which is the only way to check the estimate against reality.
What this is worth doing anyway
The weekly log is cheap — it reads existing counters, puts no load on the machine, and takes under a second. Its value is not in any one reading but in the shape that emerges after months, when the accumulated drift finally exceeds the scatter and the direction becomes unambiguous.
We have twenty days. Our older machine has four years behind it, and what its battery looks like after four years is a far clearer picture than anything a new machine can show, precisely because the signal has had time to outgrow the noise.
If you want to start your own log, the ioreg command above is the whole requirement. Record the date, the cycle count, and both capacity values. Then — and this is the part that matters — do not react to any single week.
Readings taken 24 September to 15 October 2026 on hardware we own, by automated weekly collection. Raw millamp-hour values are in the table above. Not investment advice.