Repository navigation
"Re-sync / Recalculate Sleep" option to re-detect sleep #515
Description
NOOP version
9.0.1
Platform
Android
OS version
android 13
WHOOP strap model
WHOOP 5.0
Where the data is coming from
Live Bluetooth (strap connected)
Test Centre profile
Sleep & Rest
What happens
I went to bed around 12:00 AM, woke up at 1:30 AM to watch a game, went back to sleep around 2:40 AM, and woke up at 7:00 AM.
The strap's automatic sleep detection only picked up the first segment (12:00 AM – 1:30 AM) and saved it as my main sleep session for the night. This caused several issues:
Calculations are wrong: Because the app registered only 1.5 hours of sleep, all the metrics on my Sleep tab (like Sleep Debt, Needed vs Slept, and Sleep Schedule charts) are calculated using this incorrect data. They are completely wrong, even though the "Your Data, Fused" dashboard screen correctly shows my actual sleep of 5h 28m (synced from Samsung Health/Health Connect daily metrics).
Manual sleep editor bug: When I tried to fix this by manually adding my sleep window (12:00 AM – 7:00 AM), the manual entry editor calculated a completely incorrect, inflated duration (showing that I slept for ~13 hours), so I couldn't save it.
Deleting blacklisted the night: I deleted the incorrect 1.5-hour sleep session hoping the app would re-detect the night's sleep, but it just cleared the night entirely.
Nap promoted as night sleep: Later in the afternoon, I took a nap (2:03 PM – 3:58 PM). Because the night sleep session was gone, the app promoted my afternoon nap to the main "Last Night" sleep on my Sleep tab.
What you expected instead
-
A way to re-sync or re-detect: If automatic sleep detection fails or gets split, I should be able to trigger a re-sync or recalculation. The app already has the raw heart rate (BPM) logs for that time period, so it should be able to re-scan that data to correct and verify the actual sleep window.
-
Accurate Sleep tab calculations: Sleep debt, sleep need, and schedules should be calculated using the best available data (like the fused daily metrics total), so they don't get completely thrown off by one inaccurate strap session.
-
Working manual sleep entry: When manually adding sleep, it should calculate the duration correctly based on my input rather than showing inflated times (like 13 hours).
-
No permanent lockout: Deleting a bad sleep session shouldn't permanently block that night's timeframe from being corrected or re-calculated.
-
Separate naps from night sleep: An afternoon nap shouldn't automatically take over as my main night sleep just because the night session was deleted.
Steps to reproduce
- Have a night of sleep that is split/interrupted (e.g. going to bed, waking up for a brief period, and then going back to sleep).
- The app's automatic detection fails to merge the segments, only registering the first short segment before the waking period as the main sleep session.
- Observe that the Sleep tab calculations (sleep debt, sleep need, etc.) are now incorrect because they are calculated based only on that short session.
- Try to correct this by manually adding the full night's sleep, and notice the editor displays an incorrect, heavily inflated sleep duration.
- Delete the inaccurate short sleep session to clear it. The night sleep slot is now completely empty.
- Take a nap later in the afternoon. The app will display this nap as your primary "Last Night" sleep on the Sleep tab.
Strap log
"<details><summary>Strap log (last 40 lines, redacted)</summary>
16:53:46 strap: 624249517: BLE: History burst success. Trim: 0x000
16:53:46 strap: 00009:000044ea (9:17642)
21, 624250527: BLE: Hist
16:53:46 strap: ory burst success. Trim: 0x00000009:000044ee (9:17
16:53:46 strap: 646)
21, 624250537: BLE: Historical Dump Complete
16:53:46 strap:
21, 624250537: BLE: PullStats: Data: 106, Events
16:53:46 strap: : 15, Bytes: 14460, Seconds: 2.290, Brate: 6314.4,
16:53:46 strap: Prate: 52.8
21, 624251017: BLE_CMD: Command Get
16:53:46 strap: Data Range
21, 624251037: BLE_CMD: Command Send H
16:53:46 Backfill: historical records use layout v18
16:53:46 → HISTORICAL_DATA_RESULT payload=01f044000009000000 (puffin)
16:53:46 Backfill: acked chunk trim=17648
16:53:46 Backfill: session ended — reason=HISTORY_COMPLETE
16:53:46 Backfill: session persisted 21 rows (7 with motion, 7 skin-temp) across 1 night(s).
16:53:46 Backfill: auto-continuing (#364/#451) — the trim advanced and the strap is still handing over real records (frontier 1784201025, strap-reported newest 1784201022); re-kicking offload 2/6 without waiting the 15-min floor.
16:53:46 → GET_DATA_RANGE payload= (puffin)
16:53:46 Backfill: session started — historical offload requested
16:53:46 Backfill: GET_DATA_RANGE → PENDING(2) (waiting)
16:53:46 Command response: GET_DATA_RANGE(34) → PENDING(2)
16:53:46 Get Data Range raw frame (#451 — for offset analysis): aa010c00010027112472224f02000000e9d12759
16:53:46 Backfill: GET_DATA_RANGE SUCCESS — requesting history
16:53:46 → SEND_HISTORICAL_DATA payload=00 (puffin)
16:53:46 Get Data Range raw frame (#451 — for offset analysis): aa014c00010032d12473224f010100450000f0440000f0440000f044000009000000000002000000000000001e001923e1691e4500003fbf586aeb1100003fbf586aeb11000041bf586aeb110000000012d1cd8f
16:53:46 Strap newest banked record: 2026-07-16 16:53 (from data range)
16:53:46 [universal] clockDrift newest=2026-07-16 11:23:45 wall=2026-07-16 11:23:46 newestVsWall=-1s clockOk
16:53:46 Backfill: reached the end of available history (trim=0xFFFFFFFF) - caught up; the strap handed over its banked history earlier this sync. Nothing more to offload.
16:53:46 → HISTORICAL_DATA_RESULT payload=01ffffffffffffffff (puffin)
16:53:46 Backfill: acked chunk trim=4294967295
16:53:46 Backfill: session ended — reason=HISTORY_COMPLETE
=== Capture check ===
universal: present (dayOwner day=)
sleep: present (gate run=)
import: MISSING (expected import parser=)
steps: MISSING (expected stepsEst )
INCOMPLETE: missing import, steps
bundle ok files=2 report=present meta=present screenshot=present crash=present leaks=0
</details>"
=== Detailed Sleep & Heart Rate Timeline (July 15 Night – July 16 Morning) ===
- 11:30 PM - 12:00 AM: Awake / Getting ready for bed (Avg: 89.0 bpm | Range: 66 - 106 bpm)
- 12:00 AM - 01:30 AM: FIRST SLEEP (Avg: 68.7 bpm | Range: 57 - 98 bpm)
- 01:30 AM - 02:45 AM: AWAKE / WATCHING GAME (Avg: 76.4 bpm | Range: 66 - 106 bpm)
- 02:45 AM - 07:00 AM: MAIN SLEEP (Avg: 60.3 bpm | Range: 47 - 92 bpm, hitting low of 47 bpm at 6:15 AM)
- 07:00 AM - 08:30 AM: AWAKE / WAKING UP (Avg: 69.6 bpm | Range: 54 - 91 bpm)
=== Sleep Segments Breakdown ===
1. First Sleep Segment:
- Start Time: 12:03 AM
- End Time: 1:30 AM
- Duration: 1 hour 27 minutes
2. Awake / Active Period:
- Start Time: 1:30 AM
- End Time: 2:40 AM
- Duration: 1 hour 10 minutes (Elevated heart rate averaging 76-80 bpm, max 106 bpm)
3. Second Sleep Segment (Main Sleep):
- Start Time: 2:45 AM
- End Time: 7:00 AM
- Duration: 4 hours 15 minutes (Lowest heart rate of 47 bpm reached at 6:15 AM)
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, and this isn't an already-known limit (e.g. SpO₂, or recovery/sleep on the 5/MG).
- I've left out anything personal (strap serial, account email, raw export).
Activity
ryanbr commentedon Jul 16, 2026
Thanks for the unusually detailed report and screenshots — the split-night timeline and the "13-hour" editor screenshot made this much easier to trace. These are really five distinct problems with different root causes, so splitting them out:
1. Split-night detection kept only the first segment (bug — needs data to pin).
A ~70-minute mid-night wake splits the night into sleep / awake / sleep, and the automatic re-stitch has a gap in the 60–90-minute range specifically for a dense, live-Bluetooth WHOOP 5.0 night. Confirming exactly why the second segment (2:40–7:00 AM) was dropped needs the night's raw heart-rate/motion. If you can attach a debug export covering that night, that records the per-minute HR and motion the detector actually saw — which is what's needed to tune the bridge threshold without guessing.
2. Sleep tab vs "Your Data, Fused" showing different totals (by design).
The Sleep tab (Sleep Debt, Needed vs Slept, Schedule) is computed from NOOP's own detected session, while the Fused dashboard picks the best available source and can surface the Health Connect / Samsung total — so when detection is wrong, they diverge. Whether the Sleep-tab math should fall back to the fused total is a design question to weigh.
3. Manual editor showing an inflated (~13h) duration (bug — fix planned).
The bed and wake times are committed one at a time against the existing session's other end, so an intermediate state can compute a nonsensical span and get rejected by the save guard. The fix is to take a single validated start+end window. This is the most direct path to letting you correct a night yourself.
4. Deleting a session cleared the night with no re-detect (intended, but a dead end).
Deleting an auto-detected night writes a "don't re-detect this window" marker — that's why it stayed blank. It's deliberate (so a deliberately-removed session doesn't keep reappearing), but it needs an escape hatch.
5. The afternoon nap became "Last Night" (by design, interacts badly with #4).
With the night gone, the nap was the only sleep block left, and session selection intentionally has no "must be overnight" rule (so nap-only days still show something). Worth revisiting so a clearly-daytime block isn't promoted to "Last Night".
Planned follow-up
The single most useful next thing is that debug export for the night in question — it's what unblocks the detection fix.
mohdarsal9-sudo commentedon Jul 16, 2026
Report.zip
Hope this the file you looking for, let me know if it's not ✌️
mohdarsal9-sudo commentedon Jul 16, 2026
noop_sleep_debug_per_minute_july15_16.zip
Here is the raw telemetry debug export for the night of July 15-16, 2026,
ryanbr commentedon Jul 17, 2026
Thanks for the export — it was decisive, and it overturns the theory in my earlier comment. The
[sleep]trace inReport.zipcontains the stager's own decisions for that night:Three things I had wrong:
The detection dead-zone theory is dead. I blamed the 60-90 minute bridge gap. That's not what happened.
The bridge refused correctly. It is HR-vouched: it only joins two sleep runs if heart rate stays in the sleep band across the gap. During the wake, HR ran 74-86 against a 73 baseline — above the band. You were genuinely awake watching the game, and the stager was right to keep the two apart. (Side note: the stager put your re-onset at ~02:45, which matches your "around 2:40" nicely. The strap's own band scoring was more conservative at 03:17.)
The second segment was never dropped.
run=4 spanMin=257 KEPT— 4h17m, efficiency 0.95, resting HR 50. Detection found it, kept it, and grouped the night atgroupInBedMin=416(00:03 -> 07:01). The 96-minuterun=3is exactly the "12:00 AM - 1:30 AM" you saw.So the sleep was detected — roughly 96 + 257 = ~5h53m across the night, in the right neighbourhood of the 5h28m you knew was correct. That means the fault is downstream of detection, in how a session is selected and shown as "Last Night", not in the staging. Main-night selection scores on duration, so the 257-minute block should have beaten the 96-minute one outright — that's the next thing to chase.
One caveat I want to be upfront about: this trace was captured after you had already deleted the night, and a deletion writes a "don't re-detect this window" marker that filters runs after the stager logs them as KEPT. So the two effects are somewhat entangled in this capture, and I can't fully separate them from it alone.
Two of the five items here are already fixed on main in the meantime: the manual editor now saves one validated window (#525), and there is a "Recompute this night" action that clears that deletion marker and re-runs detection (#526). Between them, the recovery path you were denied should now work.
Nothing to do on your side for now — the export gave us what was needed. Investigation continues on the selection path.
ryanbr commentedon Jul 17, 2026
Following up on my last comment — I dug further into the export and item 1 is solved. It isn't a sleep-detection bug at all.
The timeline the logs show:
So when you looked in the morning and saw 1.5 hours, that was simply all NOOP had received. The rest of the night was still sitting on the strap.
Once it did arrive, the detector got it right:
Both segments detected, both kept, ~5h53m total — right where your 5h28m sits. And the "Last Night" picker scores on duration (a block gets at most a 90-minute alignment bonus), so the 257-minute block would always have beaten the 96-minute one. Detection was fine. Selection was fine. The data just hadn't arrived.
What that means: the root cause of item 1 is NOOP's historical sync being slow — it drains a night's backlog in short bursts separated by a 15-minute floor, so a night can take hours to fully land. That's tracked in #533, and this is a much more serious symptom of it than "sync is slow": it makes your sleep look wrong for hours after you wake up. It also explains the cascade — you saw a wrong 1.5h night and reasonably tried to fix it by hand, which is how you hit items 3 and 4.
Where the five items stand:
Thanks for the export and for pushing on this — it turned a suspected sleep-staging bug into a much more useful finding about sync.
mohdarsal9-sudo commentedon Jul 17, 2026
No problem! Thanks for putting in the time to dig through it and figure it out. Really appreciate the effort
Raise backfill auto-continue cap so a deep backlog drains in one conn…
Raise backfill auto-continue cap so a deep backlog drains in one conn…
Raise backfill auto-continue cap so a deep backlog drains in one conn…
Allow hiding stale sleep recompute entries (#679)
I-Dude commentedon Jul 21, 2026
Sorry if im barking up the wrong tree, but this issue seems the most related.
I just updated to your version of the app today so I cant attest to the current sleep detection yet. but every previous version from 8.2.1 back and including the 9.0.2 that I just installed didn't (doesn't) let me edit last nights sleep properly. when I do and edit of the sleep, how does the date get assigned? Because I have numerous mis-detections across midnight. like last night, I got in bed around 11PM (July 20) but I actually went to sleep around 5AM (July 21) awake at 11AM (July 21). The 8.2.1 version detected the 11PM to 11AM. When I go to correct the data, i can only chose the time (and not the date). when i do so, it seems like it just rolls the timer without changing the date, so now it thinks my sleep was 5AM (July 20) to 11AM (July 21).
Can you add a date selection to the "adjust sleep times" menu? This would also let me edit farther back nights that are wrong as sometimes I don't check every day. I briefly used the Whoop App with a trial and their edit night has a separate date selector for both start and end of sleep.
The "Recompute this night" that was mentioned above, will there be a button available to trigger this action? (and will it be limited to only the previous night?
Edit: Im on android 16, 9.0.2 ryanbr/noop using Whoop 4.0
Edit2: After Experimenting a bit more I tricked the app into creating the correct sleep times. I recomputed the sleep, It did it wrong again (based on my heartrate I can see why it computed the 11PM sleep start time) then when on the July 20 sleep date I manually added the correct sleep times, then I deleted the original sleep. because the sleep started on July 21, it attributes the sleep to July 21 instead of July 20. I will see how well it works tonight.
Raise backfill auto-continue cap so a deep backlog drains in one conn…
Allow hiding stale sleep recompute entries (ryanbr#679)
I-Dude commentedon Jul 23, 2026
I had a similar issue today, same approximate times as 2 nights ago, 11PM,5AM,11AM. Log file attached, i dont know if it will have the information that you need. I clicked the recompute sleep at around 15:07. Is there a way of capturing more than 3 hours of logs?
noop-strap-log-260723-1508.txt
I-Dude commentedon Jul 24, 2026
More logs. timeline : 8PM playing games at computer, ~10PM got in bed to read, 2AM went to sleep, ~8:20AM got up.
noop-strap-log-260724-0127.txt
noop-strap-log-260724-0850.txt
Raise backfill auto-continue cap so a deep backlog drains in one conn…
Allow hiding stale sleep recompute entries (ryanbr#679)