I Wore Two Wearables at Once. Most of the Disagreement Wasn't Real. — Hassan Dawood

Read the study abstractThe formal Background / Method / Results / Conclusion summary of this study

Background

Apple Watch and Oura Ring readings are often treated as roughly interchangeable, but I wear both and rarely checked whether they actually agree when compared directly, night for night and metric for metric. This analysis compares sleep, heart rate, HRV, respiratory rate, SpO2, and step count using about 2 years of daily paired data, correcting two overlooked data quality issues before drawing any conclusions.

Method

Two corrections were applied to every metric before comparison. Source isolation removed steps and sleep records that Oura had written directly into Apple Health, which were contaminating Apple's own exported data. True concurrent-wear filtering restricted the comparison to days with at least 12 hours of confirmed overlap between the two devices, since they weren't always worn together. Agreement was measured with Pearson r, Lin's concordance correlation coefficient (which penalizes scale and offset error that r misses), and Bland-Altman bias and limits of agreement. Year-clustered mixed-effects models confirmed the results weren't artifacts of autocorrelated daily observations.

Results

Agreement varied widely and moved in both directions once corrected. Resting heart rate looked like the weakest metric at first (r=0.36) but turned out to be one of the strongest (r=0.877, CCC=0.544) once each device's measurement window was matched: Apple draws resting heart rate from awake stillness throughout the day, while Oura draws it from sleep only. Full-day continuous heart rate streams from both devices, a window-independent check, agreed closely on their own (r=0.848, CCC=0.847), confirming the discrepancy was a window mismatch rather than a sensor problem. Steps agreed well (r=0.78-0.85), with Oura consistently reading about 1,000 fewer steps per day. Sleep duration and stages agreed moderately (r=0.64-0.69 for duration), with Deep sleep the weakest sleep metric (r=0.34-0.39). HRV followed the same window-mismatch pattern as resting heart rate but left a genuine unexplained gap of about 18 ms even after matching sleep windows. SpO2 was the weakest metric overall (r=0.26-0.31) and, unlike the others, could not be corrected: it reflects a real measurement-window difference by design (all-day for Apple, sleep-only for Oura), not a data quality problem.

Conclusion

Most of what looks like disagreement between the two devices is a measurement-window mismatch or a data contamination artifact, not a true sensor discrepancy. Once corrected, most metrics agree closely. The two exceptions, HRV and SpO2, appear to reflect genuine differences in what each device is actually measuring, not noise that further correction would resolve.

Short version: most of what looked like my Apple Watch and Oura Ring disagreeing turned out to be contamination, missing overlap, or two devices using different definitions of "resting." Not all of it, though.

The problem

I wear an Apple Watch and an Oura Ring at the same time, and for a while I just trusted whichever number was in front of me: sleep duration from one app, resting heart rate from the other, without ever asking whether they'd actually agree if I put them side by side. That bothered me. If two devices are measuring the same body at the same time and giving me different numbers, I wanted to know which one, if either, I should believe, and why they were drifting apart in the first place.

What I built

So I pulled a full export from both devices, an Apple Watch Ultra (1st generation) and an Oura Ring (Generation 3), worn together: about a thousand nights of overlapping data since 2023, going straight to the rawest version of each device's records rather than trusting either app's own summary screen. That distinction mattered more than I expected. Apple's export can be read two ways: a quick, pre-summarized daily file, or the slow, complete record-by-record version that also tells you which physical device actually produced each number. Oura's data came in through its own API, pulling sleep, heart rate, activity, and stress separately. Once both were in hand, I built a comparison layer that lines them up night by night and metric by metric, instead of eyeballing two different apps against each other.

How the analysis actually narrowed down

Before getting into what I found, it's worth showing how the comparison got progressively stricter, because each stage removed a specific way the two devices could look more, or less, alike than they really are.

I Wore Two Wearables At Once Most Of The Disagreement Wasnt Real Analysis Funnel — I Wore Two Wearables at Once. Most of the Disagreement Wasn't Real. — I Wore Two Wearables At Once Most Of The Disagreement Wasnt Real Analysis Funnel

How it works, and where it got messy

The first surprise had nothing to do with accuracy, and it was mostly my own doing: I'd enabled Oura's Apple Health integration, which Oura's own documentation confirms syncs sleep duration, sleep stages, and heart rate straight into Apple Health in the background. So Oura had been quietly writing its own sleep data into Apple Health the whole time, and a naive comparison was often just comparing Oura against a copy of itself, which made an early, reassuring-looking agreement number almost meaningless. Once I isolated only the nights where each device's own sensor did the measuring, the real agreement was noticeably weaker than it first appeared. Most people won't hit this unless they've turned that integration on, but it's a real trap for anyone doing research with HealthKit-merged data. The source of a given record isn't obvious just from looking at it. It turned out sleep wasn't the only metric affected: a full audit found Oura is also the single largest contributor to my Apple Health step count, and about a quarter of my continuous heart rate data too.

The heart rate side had its own trap. On paper, resting heart rate looked like the two devices disagreed more and more as heart rate went up: a pattern that looked like a real physiological finding. It wasn't. Apple's day-to-day resting heart rate number is simply noisier than Oura's, and a noisier instrument's most extreme-looking readings are disproportionately likely to be flukes that snap back toward average the next time you measure, a statistical mirage called regression to the mean, not a real trend. Testing that theory directly matched almost exactly. The same check, run against sleep and HRV too, found the identical thing: three separate "the devices disagree worse in extreme cases" patterns, all statistical noise dressed up as biology.

The most interesting gap, though, came down to timing rather than technology. This isn't a guess on my part. Both companies say so directly. Apple's own methodology paper describes resting heart rate as built from background readings taken during the most inactive parts of the day, explicitly excluding Sleep Focus, scheduled bedtime, and sleep itself: it's "an estimation of the user's lowest heart rate during periods of rest while awake." Oura's help center, on the other hand, describes RHR as captured every ten minutes overnight: a sleep-only number, with no separate "awake resting" metric at all. Those aren't the same number to begin with. But simply restricting Apple's readings to Oura's overnight window barely moved the correlation at all, which meant the gap wasn't really about which clock-hours got compared. It only resolved once I stopped comparing two different pre-built summaries and instead recomputed both devices' heart rate from raw, continuous data, restricted to the same physiological state: on Apple Watch alone, heart rate while awake and resting (about 65 bpm) sat a genuine ten beats above heart rate while asleep (about 55 bpm), real circadian physiology, not sensor drift. Once I compared Apple's own sleep-only heart rate against Oura's sleep-derived number (same state, different sensors), the two landed within about half a beat per minute of each other.

I Wore Two Wearables At Once Most Of The Disagreement Wasnt Real Heart Rate By Hour — I Wore Two Wearables at Once. Most of the Disagreement Wasn't Real. — I Wore Two Wearables At Once Most Of The Disagreement Wasnt Real Heart Rate By Hour

What I found

Bottom line: most of what looked like device disagreement wasn't about the sensors at all. It was contamination, missing overlap, or two devices defining the same word differently. Two real disagreements survived anyway.

Once the contamination and timing issues were sorted out, most of the picture cleaned up. Sleep duration disagreement is real but modest: comparing only genuinely independent nights, Oura reads about 35 minutes longer than Apple on average, tracking loosely rather than tightly night to night. The two devices' raw, continuous heart rate sensors agree closely, correlated above 0.84 across a full day in five-minute windows, which is what let me rule out "one sensor is just bad" as an explanation for anything else. And the headline resting-heart-rate gap collapsed almost entirely, down to about half a beat per minute, once I recomputed both devices' heart rate from raw data restricted to the same physiological state, rather than comparing Apple's awake-resting number against Oura's asleep one.

Two things didn't fully resolve. HRV moves the right direction on Apple Watch alone, about 44ms awake to about 68ms asleep, the expected circadian shift, but even comparing both devices' sleep-only numbers directly, an 18-millisecond gap remained, a meaningful chunk of a ~50ms reading. Apple discloses it computes HRV using SDNN; Oura never names its method anywhere in its own documentation, so the two may simply be incompatible calculations of the same idea, not measurement error. Separately, restricting every comparison to hours both devices were genuinely worn together (they were often worn independently, one dead while the other stayed on) improved sleep, step count, and HRV agreement, and left resting heart rate completely unchanged, exactly as the circadian explanation predicts it should.

Sleep-stage detail is the clearest open disagreement in the study. After fixing both the contamination problem and the wear-time problem, Core sleep agreement improved, but Deep sleep barely moved either time, landing at a concordance of about 0.27 on a scale where 1.0 is perfect agreement. That's a weak result, and it's no longer explainable as a data artifact: Apple and Oura's Deep-sleep classification algorithms appear to genuinely disagree with each other.

I Wore Two Wearables At Once Most Of The Disagreement Wasnt Real Sleep Stage Duration — I Wore Two Wearables at Once. Most of the Disagreement Wasn't Real. — I Wore Two Wearables At Once Most Of The Disagreement Wasnt Real Sleep Stage Duration

What this means for research relying on wearables

This is where the finding stops being a personal curiosity and starts mattering for anyone doing research on consumer wearables. A ring on the finger and a watch on the wrist are genuinely different sensor placements, sampling at different rates, and it's notable that their raw, continuous heart rate signal agreed as closely as it did. Modality mattered far less than expected for accuracy. It mattered more for something less obvious: battery life. My Oura Ring runs about five days on a charge; my Apple Watch, at best, two, so I'd occasionally forget to charge the Watch and simply lose a night's data, while the Ring almost never had a gap. That's not a sensor problem, but it's a real one for research: if one device drops more nights than another, and it's not random which nights (travel and illness both make you more likely to forget a charge), that's a bias baked into the hardware before a single number is even compared.

What mattered more was what each company's software did with the signal afterward: which time window counts as "resting," how sleep stages get classified, how noisy days get smoothed. If the underlying sensors agree but a vendor's summary metrics don't, the discrepancy isn't measurement error: it's two different, largely invisible analytic pipelines applied to similar raw signal (Apple discloses its HRV method as SDNN; Oura never names its method anywhere in its own documentation, so even a motivated reader can't tell whether the two numbers mean the same thing). A study working only from each vendor's daily summary has no way to see that or correct for it. That's a real argument for staying as close to raw or continuous data as a vendor allows, especially once a study needs more than one wearable: a multi-year cohort spanning hardware generations, a multi-site study standardized on different devices, or a bring-your-own-device study where participants show up wearing whatever they already own. Stitching together vendor-summarized metrics across any of those scenarios means silently stitching together incompatible pipelines, exactly the trap this whole comparison fell into by accident.

It also cuts the other way, and it's worth saying so plainly: not every gap dissolved once I controlled for contamination, wear time, and window mismatches. Deep sleep staging didn't, and HRV only half did. That's arguably the most useful result in the whole exercise: proof this isn't a trick for making all device disagreement disappear. Sometimes, after every known confound is accounted for, two devices really do disagree, and a study that stops digging at the first plausible explanation would have missed that.

What I didn't expect

I went in assuming the interesting question was "which sensor is more accurate." It turned out to be "what is each device actually choosing to measure, when, and how often was it even measuring both devices at once": most apparent disagreement was really about definitions, timing, and overlap, not accuracy. I also learned the obvious fix isn't always the right one: my first attempt to correct for missed wear time (restricting every metric to the exact minutes both devices overlapped) made agreement worse almost everywhere, because the overlap data was too fragmented to use that precisely. A coarser version worked; a version targeted at specific confirmed gaps worked better still. Watching a plausible fix fail clearly taught me more than a lucky one succeeding quietly would have.

What's next

The HRV and Deep-sleep gaps are the two open threads. Closing either would need raw beat-to-beat data neither company exports today. I'd also like to see whether they widen during travel, illness, or genuinely poor sleep, in this or future rounds of the handful of small self-run studies I keep on my own health data.

Sources

Apple, Heart Rate and Calorimetry Algorithms for Apple Watch

Apple Developer, HKQuantityTypeIdentifier.restingHeartRate

Oura Help Center, Resting Heart Rate

Oura Help Center, Apple Health Integration

Oura Help Center, Heart Rate Variability

Wikipedia, Concordance correlation coefficient (the agreement statistic used throughout this analysis, alongside plain correlation)