You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[iOS] HRV is not recorded and doesn't calibrate #2335
I just got my Whoop yesterday, and went to sleep. When I woke up today the app says that no HRV was recorded even though I slept with it and even have the Sleep tab filled with data. I didn't have the test centre enabled but exported a log for this.
What you expected instead
I was expecting to have HRV measure so the app starts calibrating
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).
Thanks @rodrigosa7, this log is a clean reproduction of #1118, which is currently labelled not reproducible. It is not a display bug.
Your night stages fine (totalSleepMin=446 eff=0.95) and the beats arrive: 45,897 of them, meanNN=1125ms. But coverage=1.83, meaning the night banks 1.83 seconds of beat time per second of wall clock where about 1.0 is possible. That verdict is crossSecondOverCount, and SleepStager.sessionAvgHRV refuses such a night outright rather than publish an RMSSD built on doubled beats. That one gate feeds the daily row, the card and the baseline, which is why HRV is blank and why calibration never advances. One cause, both symptoms.
Two cheap explanations are ruled out by your own data:
Those are value ratios. tick is the 1024/1000 unit-mismatch signature (4%), same is identical rows re-inserted (2%). 94% are genuinely different beats, median 4.9% apart, which is ordinary variation.
The useful part is that each offload batch looks correct on its own:
Every batch sits near ratio 1.0, yet the night totals 1.83, and 18,844 of your 24,545 seconds carry two delivery starts rather than one. So the doubling appears in the accumulation, not in any single record. That is new for #1118 and narrows it a long way.
Nothing is wrong with your strap or your setup, and there is no setting to change. Tracking it on #1118.
If you are willing: a Test Centre capture (Connection and Sync) over a night would carry the pre-storage census, which should show whether the second delivery enters at ingest or at insert. No rush, and your ordinary use is unaffected apart from the blank.
Thanks for the explanation @ryanbr !
I'll activate the Connection and Sync logs, and tomorrow morning after I wake up will upload it here or in #1118 if you prefer!
If you need anything else from my side just let me know!
Cheers
FYI: I had the same issues with no HRV being measured on a Whoop 5.0/MG with versions 11.5.0 and 11.7.0. I reverted back to 11.1.0 where it works fine.
Activity
ryanbr commentedon Sep 19, 2026
Thanks @rodrigosa7, this log is a clean reproduction of #1118, which is currently labelled not reproducible. It is not a display bug.
Your night stages fine (
totalSleepMin=446 eff=0.95) and the beats arrive: 45,897 of them,meanNN=1125ms. Butcoverage=1.83, meaning the night banks 1.83 seconds of beat time per second of wall clock where about 1.0 is possible. That verdict iscrossSecondOverCount, andSleepStager.sessionAvgHRVrefuses such a night outright rather than publish an RMSSD built on doubled beats. That one gate feeds the daily row, the card and the baseline, which is why HRV is blank and why calibration never advances. One cause, both symptoms.Two cheap explanations are ruled out by your own data:
Those are value ratios.
tickis the 1024/1000 unit-mismatch signature (4%),sameis identical rows re-inserted (2%). 94% are genuinely different beats, median 4.9% apart, which is ordinary variation.The useful part is that each offload batch looks correct on its own:
Every batch sits near ratio 1.0, yet the night totals 1.83, and 18,844 of your 24,545 seconds carry two delivery starts rather than one. So the doubling appears in the accumulation, not in any single record. That is new for #1118 and narrows it a long way.
Nothing is wrong with your strap or your setup, and there is no setting to change. Tracking it on #1118.
If you are willing: a Test Centre capture (Connection and Sync) over a night would carry the pre-storage census, which should show whether the second delivery enters at ingest or at insert. No rush, and your ordinary use is unaffected apart from the blank.
rodrigosa7 commentedon Sep 19, 2026
Thanks for the explanation @ryanbr !
I'll activate the Connection and Sync logs, and tomorrow morning after I wake up will upload it here or in #1118 if you prefer!
If you need anything else from my side just let me know!
Cheers
Health: say why HRV is blank when the night over-reported R-R (#2335)
Health: say why HRV is blank when the night over-reported R-R (#2335)
rodrigosa7 commentedon Sep 21, 2026
Hey again @ryanbr
Just want you to know that the issue persists and I left the logs on the other issue #1118
It keeps saying that didn’t record HRV :/
mwld commentedon Sep 23, 2026
FYI: I had the same issues with no HRV being measured on a Whoop 5.0/MG with versions 11.5.0 and 11.7.0. I reverted back to 11.1.0 where it works fine.
rodrigosa7 commentedon Sep 23, 2026
Can confirm that downgrading to 11.1 works thanks @mwld
sartoiu commentedon Sep 25, 2026
Still no HRV in new version, thanks downgrading to 11.1 works just fine
WHOOP 4 R-R sources: repin the ingress test, pair extractStreams
mwld commentedon Oct 14, 2026
Got this bug fixed with #2441 in 12.0.0 @rodrigosa7 ?