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.

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

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.