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
Effort on top and strain in key metrics no longer the same #1001
Since the last update the effort score is calculated more effectively/ as expected. But the stain score is no longer the same. Potentially also elsewhere a discrepancy (coupled view?).
What you expected instead
The same scores everywhere.
Steps to reproduce
See results in screenshot.
Strap log
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).
Added live strain computation in load() function (computes strain from HR samples since midnight for TODAY)
Added effortStrain(_:) helper function mirroring classic TodayView's logic
Updated both hero Effort ring and Key Metrics Effort tile to use effortStrain(displayDay)
Now for TODAY, both the hero ring and Key Metrics tile show the live in-progress effort (floored at the stored value to prevent drops), and for past days both show the stored daily value.
Confirmed from the screenshot, and it is a display inconsistency rather than a scoring one — the 2.3 is right and the 0.5 is stale.
Effort is shown in three places on Today, and only one of them recomputes:
the hero ring takes the live in-progress value, integrating today's HR from local midnight to now, floored at the day's already-earned Effort — 2.3
the Key Metrics tile reads the last persisted daily row — 0.5
the HR chart's edge badge reads the same persisted row — 0.5
That row is only rewritten when the heavy daily pass runs. Your chart shows HR flat at 44–57 overnight and then climbing hard from about 09:00, with the screenshot taken at 12:22, so the stored row predates this morning entirely. The hero counts that climb; the other two have not seen it yet.
Recovery and Rest match across all their read-outs precisely because neither has a live path — nothing to disagree with.
Not caused by the 9.3.0 Effort change, though I understand why it looks that way. The live hero landed in v4.0.1 on 15 June and the Key Metrics tile has read the stored column unchanged since 14 June, so the split is about six weeks old. What 9.3.0 changed is how the score is weighted, which makes the live number track an active morning more closely — so the gap against a stale stored row is wider and finally visible. Your read that Effort itself now behaves better is the same change.
Both platforms have it. iOS is the clearer illustration: there is already a helper whose entire job is to be the one effective value, and whose own comment says it should feed "the hero ring AND every Effort read-out, so they stay consistent" — but the tile and the chart badge each reach past it to the stored column.
Fixing it properly, on both platforms: resolve Effort once and give the tile and the badge the same value the ring gets, keeping the never-drop floor so a sparse-HR moment cannot make any of them fall. Will do that as its own PR.
Effort is resolved once and every read-out uses that figure — the hero ring, the Key Metrics tile and the chart's edge badge. The tile and the badge were reading the daily row, which only refreshes when the heavy daily pass runs, so on a morning like yours they trailed the ring by the whole morning's load.
The screen-reader description on the heart-rate chart had the same wrong number and is fixed by the same change.
Two things worth saying since you spotted this from the numbers rather than a crash: the 2.3 was the correct one, and your read that Effort itself now behaves better is a real change (#963) — it tracks an active morning more closely, which is what made the stale figure obvious.
It will be in the next release. Thanks for the screenshot with both values in frame; that is what made it diagnosable without a log.
Activity
KOUSHIK-9 commentedon Jul 31, 2026
Problem: The "Effort" score shown in the hero rings (top of screen) and the "Key Metrics" grid were out of sync for TODAY.
Root Cause:
Fix Applied (both TodayView and LiquidTodayView):
Now for TODAY, both the hero ring and Key Metrics tile show the live in-progress effort (floored at the stored value to prevent drops), and for past days both show the stored daily value.
pilleuspulcher-blip commentedon Jul 31, 2026
For me it's okay, effort on top of today' and effort (Belastung) in key metrics are equal. But I use a Whoop 4.0. 🤔
bartmuskala commentedon Jul 31, 2026
Now it is also the same again. Before it was not. Sometimes it is not in sync, moments/a while later it is.
ryanbr commentedon Jul 31, 2026
Confirmed from the screenshot, and it is a display inconsistency rather than a scoring one — the 2.3 is right and the 0.5 is stale.
Effort is shown in three places on Today, and only one of them recomputes:
That row is only rewritten when the heavy daily pass runs. Your chart shows HR flat at 44–57 overnight and then climbing hard from about 09:00, with the screenshot taken at 12:22, so the stored row predates this morning entirely. The hero counts that climb; the other two have not seen it yet.
Recovery and Rest match across all their read-outs precisely because neither has a live path — nothing to disagree with.
Not caused by the 9.3.0 Effort change, though I understand why it looks that way. The live hero landed in v4.0.1 on 15 June and the Key Metrics tile has read the stored column unchanged since 14 June, so the split is about six weeks old. What 9.3.0 changed is how the score is weighted, which makes the live number track an active morning more closely — so the gap against a stale stored row is wider and finally visible. Your read that Effort itself now behaves better is the same change.
Both platforms have it. iOS is the clearer illustration: there is already a helper whose entire job is to be the one effective value, and whose own comment says it should feed "the hero ring AND every Effort read-out, so they stay consistent" — but the tile and the chart badge each reach past it to the stored column.
Fixing it properly, on both platforms: resolve Effort once and give the tile and the badge the same value the ring gets, keeping the never-drop floor so a sparse-HR moment cannot make any of them fall. Will do that as its own PR.
Effort: one resolved figure for every read-out on Today (#1001) (#1006)
ryanbr commentedon Aug 1, 2026
Fixed in #1006, on
mainnow.Effort is resolved once and every read-out uses that figure — the hero ring, the Key Metrics tile and the chart's edge badge. The tile and the badge were reading the daily row, which only refreshes when the heavy daily pass runs, so on a morning like yours they trailed the ring by the whole morning's load.
The screen-reader description on the heart-rate chart had the same wrong number and is fixed by the same change.
Two things worth saying since you spotted this from the numbers rather than a crash: the 2.3 was the correct one, and your read that Effort itself now behaves better is a real change (#963) — it tracks an active morning more closely, which is what made the stale figure obvious.
It will be in the next release. Thanks for the screenshot with both values in frame; that is what made it diagnosable without a log.
merge: upstream 9 commits (post-9.3.0) into main
release(9.3.1): version identity, release notes, What's New
Effort: one resolved figure for every read-out on Today (ryanbr#1001) (…
fix(today): give Liquid Today the live in-progress Effort classic alr…
Resolve the Liquid view's Effort through the live/stored floor too
Read the whole day for live Effort, not the first 8000 samples
today: stop the Liquid Effort tile calling a load index a percentage