RMSSD vs SDNN: why HRV numbers differ between apps
Journal · 2026-09-15 · R. Klug · All notes
Read in: Deutsch · Français · Español · Italiano
Wear two devices for a week and you will have two “HRV” columns that disagree — sometimes by a factor of two. Before concluding that one sensor is broken, look at the label on the column. In most cases the gap is not the hardware. It is the statistic.
Two summaries of the same sequence
Every HRV metric starts from the same raw material: the series of intervals between consecutive heartbeats. The metrics differ in what they summarise.
- RMSSD — root mean square of successive differences — looks only at how much each interval differs from its immediate neighbour. It captures fast, beat-to-beat variation, which is dominated by parasympathetic activity. This is the statistic most sports-science HRV work is built on, usually log-transformed (lnRMSSD) and averaged over a window.
- SDNN — standard deviation of all intervals in the window — mixes fast variation with every slow drift in the same period. Over 24 hours it reflects total variability; over a short window it becomes strongly dependent on how long the window is and what happened in it.
Same heart, same night — different mathematical questions, different numbers. Neither is wrong. They are answers to different questions, and they cannot be compared to each other in absolute terms.
What Apple Health stores
Since iOS 11, the HRV type in Apple Health has been SDNN, computed from short measurement snippets — which is why Health values never match an RMSSD-based app, and why apps that read HRV from Health inherit both the statistic and the sampling schedule of whatever wrote it. With iOS 27, Apple added a separate RMSSD type alongside it, which narrows the gap for newer sources — but any Health-imported value still carries its source’s window, timing and device with it. ampulse therefore labels Health-imported HRV as exactly the statistic the source supplied, rather than pretending it is comparable to its own chest-strap or Loop-derived windows.
Three more reasons two apps disagree
- Window and timing. A five-minute morning reading, a whole-night average and an on-demand spot check sample different physiological states. HRV also swings within a single night, so “which part of the night” alone moves the number.
- Artifact handling. A single missed or doubled beat, uncorrected, can inflate RMSSD by several hundred percent (Bourdillon et al. 2022). Apps correct differently — or not at all — and rarely say so.
- The sensor’s access to the signal. A chest strap detects each beat electrically and transmits the intervals; optical sensors estimate beats from blood flow and vary widely in how faithfully intervals survive. When the app receives raw intervals, the statistic can be computed transparently; when it receives a pre-computed score, nothing can be verified.
The one rule that keeps trends honest
Pick one statistic, one device, one measurement context — and compare yourself only against your own history in that method. Cross-method comparisons of absolute values are noise wearing the costume of information. This is also why ampulse keeps the beat intervals themselves on file: a stored raw sequence can be re-computed under any statistic, today or years from now, and every derived number remains checkable against the record that produced it.