Charge score stuck since 14th Sep

[willbafc-bit]

NOOP version

11.8.0

Platform

iOS

OS version

26.6.2

WHOOP strap / Oura ring model

WHOOP 5.0

Where the data is coming from

Live Bluetooth (WHOOP strap connected)

Test Centre profile

Not a test-mode bug

What happens

Since the 14th September my charge score is stuck at 79 and not updating. My RHR and HRV is continuing to record daily as well as stress, sleep, effort etc... all other metrics are fine.

I switched from side store stable to nightly as was aware of latest ios not allowing you to re-download NOOP under stable before expiry, I believe its since the switch this might be happening. Although I'm not diagnosing that to definitely be the reason, i'll leave that down to the experts!

I couldn't find anything on git hub with this same issue, only the charge score not showing up due to not being calibrated but mine is well calibrated.

The strap log seems to be picking up everything but maybe you can see a discrepancy in there...?

p.s. i've tried to upload lines from the strap log which are the most relevant/which show the key metrics feeding in without the charge score being generated

What you expected instead

The charge score to change daily and be updated as normal

Steps to reproduce

1. See whats causing charge score to be stuck since 14th sep whilst all other metrics including those which calculate charge score continue to record and save.

Strap log

[06:04:47] Backfill: session ended — reason=HISTORY_COMPLETE
Backfill: session persisted 2147 rows (707 with motion, 707 skin-temp) across 1 night(s).
Backfill: rows landed on 2026-09-18
...reached the end of available history... caught up
re-score: trigger=idle newData=yes
Backfill: refreshing dashboard cache from completed sync

rhr day=2026-09-18 floor=38 nightMean=47...
resp day=2026-09-18 rpm=14.1
sleep day=2026-09-18 totalSleepMin=474 ... eff=0.96
hrv day=2026-09-18 window=whole avgHrv=89.7
hrv diag day=2026-09-18 rmssd=90ms ... rrIntegrity=plausible

analyzeRecent ... baselines=17ms score2=3562ms ... persist=9ms
re-score: done — scored 21 night(s) in 36005 ms

Before you submit

• I attached my exported NOOP .zip (not a screenshot of the Live screen). If my bug is a clearly reproducible UI issue I described exactly how to see it instead.
• I attached or pasted a strap log above — or my bug is a clearly reproducible UI issue that doesn't need one (e.g. a typo, a button that does nothing) and I've described exactly how to see it.
• I checked the Troubleshooting guide — especially "history syncs but no data" (most often the strap isn't banking history to flash; charge it to 100% and reconnect).
• I checked the FAQ and — if I'm on a WHOOP 5.0 / MG — the 5.0/MG status page, or — if I'm on an Oura ring — the Oura ring support table, and this isn't an already-known limit (e.g. SpO₂, recovery/sleep on the 5/MG, or no Recovery / HRV on a ring-only day).
• I've left out anything personal (strap serial, account email, raw export).

[ryanbr]

Thanks @willbafc-bit, and the log excerpt is enough to narrow this a long way.

The 79 is the carry, not a stale write

Charge carries the most recent SCORED value onto today so the tile does not blank at the
rollover. A frozen 79 therefore means no night since the 14th has produced a recovery value
at all, and the tile is faithfully showing the last one that did. Everything else you list
keeps updating because each of those is written independently of the recovery composite.

So the question is not why Charge is stuck. It is why recovery stopped being produced while
its inputs kept arriving.

Two of the three inputs are in your log

Recovery needs three things, and your own lines supply two of them for the 18th:

hrv  day=2026-09-18 window=whole avgHrv=89.7   rrIntegrity=plausible
rhr  day=2026-09-18 floor=38 nightMean=47
re-score: done - scored 21 night(s) in 36005 ms

HRV is there, resting HR is there, and the pass ran. The third input is the personal HRV
BASELINE, and recovery is withheld until that baseline is usable, which needs a minimum
number of valid nights behind it. That is the one thing your excerpt cannot show, and it is
now the only candidate left on this path.

What I ruled out

The timing pointed straight at #2115, which preserves WHOOP 5 HRV and recovery across a
re-score and landed on the 12th, two days before your onset. A preservation gate that holds
a value when a pass cannot recompute it is exactly the shape that freezes a number.

It does not apply to you. That path is entered only when the pass produced NO HRV for the
day, and yours produced 89.7, so it never runs. Worth saying because it is the obvious
suspect and it is innocent here.

The SideStore switch is plausible on timing but one mechanism is already excluded: the
background task identifiers are derived from the bundle id, so a different id would stop the
re-score being scheduled. Your log shows a re-score completing, so that is not it.

Three things that would settle it

1. Have you used Settings, Recalibrate HRV baseline at any point around the 14th? That
   discards every night before it and restarts the seeding count, and the span from the 14th
   to now is about the right size for a seeding window that has not closed yet.
2. Does the Charge tile show a date caption under or beside it, something like
   "Last night" with a date? If it names the 14th, that confirms the carry outright.
3. The full exported .zip rather than the excerpt. The analyzeRecent line reports
   baselines=17ms, which is how long the fold took, not how many valid nights it found.
   The export carries the state itself.

If the answer to 1 is no, that is genuinely useful too: it means the baseline went unusable
without anyone asking it to, which is a different and more interesting bug than a seeding
window.

[ryanbr]

One more thing worth knowing, and it may matter more than the questions above.

A re-score pacing bug landed today, in #2318. It produces a symptom
shaped like yours, and the log stayed silent about it, which is why it took a
database pull rather than a log read to find.

The mechanism

A backgrounded pass rested after every night. A rest is a sleep, and a
backgrounded process that is only sleeping is what iOS suspends, until the next
bluetooth wake roughly ten minutes later. Each night is milliseconds to a few
seconds of work, so a backgrounded pass advanced about one night per wake and
could hold the re-score lock for many hours. On the phone that surfaced it, a
full-history pass took the lock at 21:34 and still held it after 11:00 the next
morning.

Every pass triggered in the meantime returned at the lock and did nothing, and
said nothing about it. The result on that phone was a night that was never
scored: no daily row, no session.

Why it is not a clean match for yours

Your excerpt shows a pass completing:

re-score: done - scored 21 night(s) in 36005 ms

So a pass did finish for you, which the phone above never managed. Your HRV,
resting HR and sleep all landed for the 18th too. I am raising it because it is
the closest known mechanism to "every input arrives and recovery does not", not
because the evidence points at it yet.

What changes for you

On a build carrying #2318 two things are different. A backgrounded pass now
works in ten-second stretches rather than resting after each night, so it should
finish in one sitting instead of being suspended most of the way through. And a
pass that is blocked behind another now says so:

re-score: queued behind a 4000-day pass running for 812 s

That line is the evidence that was missing from your excerpt. If Charge is still
stuck on a build with this in, the log should now either name the pass holding
things up or show nothing of the sort, and those two point in very different
directions.

The three questions above still stand, and the export is still the fastest way
to settle this. The recalibration one in particular is cheap to answer and would
either explain it outright or rule out the most likely remaining cause.

[willbafc-bit]

Hi @ryanbr

1. No I have not recalibrated HRV baseline around 14th, unless re-installation of app via nightly caused this by its download, but like you say, based on all the other metrics being there and in sync since prior to this, I doubt this is the reason.
2. The charge tile shows no date but in the charge log the latest showing date is indeed the 14th with a score of 79, indicating no new score since and a daily carry since.
3. I have attached the zip which I exported from test centre under recovery, please let me know if this is what you wanted to help diagnosis

Thanks

noop-recovery-iOS-v11.8.0-260918-1149.zip

[ryanbr]

Thanks @willbafc-bit, that export carried more than it looks, and it corrects something I told you.

One correction first

I said #2115 does not apply to you because your pass produced an HRV value. That was true of the 18th, which was the only night I could see at the time. Across the 21 nights in the window it is not: HRV recomputes as nil for 18 of them, every night from 29 Aug through 15 Sep. Only the 16th, 17th and 18th produce a value, each with plausible R-R integrity and 94 to 95% coverage.

So the preservation path in #2115 IS being entered for those nights, and it is very likely why the 14th still reads 79 instead of blanking. That is the feature working, not the bug.

Sleep, resting HR, respiration and effort all compute cleanly for all 21 nights. It is HRV alone that stops, which is the useful part.

What I cannot tell yet

Two possibilities remain and your log cannot separate them: either the HRV baseline is not usable (so no night scores and everything is carried), or the baseline is fine and the rows for the 15th onward are not being written.

Both are answered by two lines that only appear while Recovery mode is actually running, and neither was in this export: the per night charge day= line, and the HRV baseline fold trace added in #1614, which states the baseline's state and its valid night count outright.

The one thing to change

Your export was taken about 40 seconds after you armed the profile, so it captured the previous session's log and none of the traced work. The order matters:

1. Turn Recovery mode on in Test Centre.
2. THEN force a re-score and let it finish.
3. Then export.

Please do it on the testing build

Two reasons. Your 11.8.0 sideload predates the re-score pacing work that landed in #2318, so a pass on your build can still stall silently, and the log line that would show it is not there to find. The testing build also carries the newer diagnostics.

https://github.com/ryanbr/noop/releases/tag/testing-latest

It installs beside the official app with its own data, so nothing you have now is touched.

Separately I am going to look into the HRV nil run on its own, whatever Charge turns out to be doing. R-R is being read across that whole window, and the boundary landing three nights before your export looks more like a retention or window selection effect than anything to do with the 14th.