Sleep Stages Without a Wearable: What a Phone Can and Cannot Detect

HKCategoryValueSleepAnalysis includes asleepDeep and asleepREM [1]. Health Connect’s SleepSessionRecord accepts a full stage breakdown [2]. Both schemas are complete, and neither platform will produce a single stage from a phone.

The interesting part is not the missing sensor. It is that no consumer device measures sleep stages at all, including the one on your wrist. What wearables are actually doing is the thing that tells you where the phone-only ceiling sits, and why it sits exactly there.

Nobody measures sleep stages except a sleep lab

Sleep staging is defined against brain activity, and nothing on your wrist records brain activity.

Stages are scored in 30-second epochs from EEG, EOG and EMG, per the AASM manual [3]. REM is not a heart rate pattern or a stillness threshold; it is an electrical signature read from the scalp.

A wrist device has none of that. It has a PPG sensor against skin, an accelerometer, and on some models temperature or SpO2, and it runs a classifier over them that emits stage labels, trained against laboratory scoring.

How well that works is measurable, and it has been measured. A multicentre validation put eleven consumer trackers against polysomnography across 349,114 epochs from 75 participants [4]. Cohen’s kappa for stage agreement ranged from 0.06 to 0.56. Not one device reached substantial agreement. The Apple Watch Series 8 scored 0.2976. The Fitbit Sense 2, among the stronger performers, scored 0.4185. Macro F1 across stage classification ran from 0.26 to 0.69.

That is the evidence base under a figure your product will render to the minute. “1 hour 42 minutes of deep sleep” is a classifier output with a kappa in the fair-to-moderate band, displayed with a precision the method does not possess.

The three inputs a phone cannot produce

Stage classifiers run on continuous heart rate, heart rate variability and fine-grained motion. A phone can supply exactly none of them while you are asleep.

The middle row is the one that ends the argument. Heart rate variability requires beat-to-beat interval timing from a sensor held steadily against skin for hours. A phone face-down on a bedside table is not touching the user at all. There is no clever engineering that recovers a signal the hardware never had a chance to observe, which is why an iPhone returns an empty array rather than an approximation when you query heart rate for a user with no Watch.

This is also why the platform behaviour looks inconsistent. Apple removed phone-based sleep tracking in iOS 18, so an iPhone alone no longer writes sleep analysis to HealthKit, though the Health app still shows a Sleep section. We covered what that removal did to products depending on it in December 2024. Health Connect on Android will happily accept a SleepSessionRecord containing stages [2], because the schema is designed for whatever wrote it. Neither platform generates stages from the phone. One stopped pretending, the other never claimed to.

What the phone does have

A phone is a poor sensor for physiology and a surprisingly good sensor for behaviour.

Across a night it can observe motion from the accelerometer, screen state, unlock events, charging state and app usage. None of that tells you anything about autonomic nervous system activity. All of it tells you a great deal about when a person stopped interacting with the world and when they started again.

That yields sleep timing: an estimate of onset and wake, and therefore duration. The published agreement here is better than the scepticism usually assumes. A longitudinal study comparing smartphone-sensed sleep against wrist actigraphy and daily diaries found no significant difference in mean bedtime, risetime or time in bed across the three methods [5]. Against actigraphy the true positive rate was 83.7% with a false positive rate of 8.5%, and bedtime and time-in-bed correlated at r=0.38 to 0.55. It is a small study, 29 participants with 13 in the actigraphy subset, so read it as directional rather than settled.

From a run of nights, timing alone produces a surprising amount:

• Regularity, the night-to-night variance in when sleep starts and ends
• Social jetlag, the shift between working days and free days
• Sleep debt, accumulated shortfall against an individual baseline
• Circadian alignment, whether sleep sits where the body clock expects it
• Disruption, a break from an established pattern, which is often the signal that actually matters

Every one is computed from when sleep happened rather than what happened during it. None of them need architecture.

They are also, for most behavioural products, the more useful set, and there is evidence behind that rather than just preference: disturbed sleep timing is one of the better-established early signals in the mental health literature, preceding depressive episodes by as much as three years. No stage breakdown is required to detect it. A user whose bedtime has drifted two hours later across three weeks has a finding worth surfacing. A user whose deep sleep was 14% instead of 18% has a number, and it is not clear what either of you should do about it.

Where phone-based sleep detection actually breaks

The failure modes are behavioural, not technical, which makes them easy to miss in testing and impossible to miss in production.

• The phone on the desk. A user who charges their phone in the kitchen produces a stillness window that starts when they leave the room, not when they fall asleep. This is the single largest source of error.
• An hour of reading in bed. Motion is near zero and the screen is on. Onset detection that leans on stillness will fire early; detection that leans on screen state will fire correctly, which is why neither signal alone is sufficient.
• Naps. A stillness window at 3pm is either a nap or a long meeting. Without a plausible circadian prior you will label some of each wrongly.
• Shift work. Almost every heuristic carries a hidden assumption that sleep happens at night. For a nurse on rotating shifts, that assumption is false several times a month.
• Co-sleeping and shared beds. A partner’s movement contaminates a nightstand accelerometer, though far less than it contaminates a mattress sensor.
• The second device. A user with a tablet in bed looks awake on one device and asleep on another, and your pipeline has to decide which to believe.

These are not speculative. The authors of that smartphone validation name two of them directly: the method may not reliably detect daytime naps, and it struggles to distinguish going to bed from going to sleep [5]. Neither is exotic. All of them are ordinary human behaviour, and each one puts a hard floor under how accurate any phone-derived estimate can be for an individual night. Population-level patterns hold up considerably better than any single night does, which is the right way to use the data.

The decision this actually makes for you

The question is never “is phone sleep data good enough”. It is “which sleep question does my feature ask”.

If your feature reports architecture, a REM percentage, a deep sleep target, a recovery score derived from either, then it requires a wearable. Not a better algorithm. The inputs do not exist, and a product built on them simply does not function for the user who owns no wearable.

If your feature is about timing, consistency or change, bedtime drift, sleep debt, routine disruption, weekend shift, then phone-derived timing serves it, and you reach the majority of users rather than the minority who own a wearable.

The trap is designing for the first and discovering the second is what you needed. Teams reach for stages because they are legible and look impressive on a screen, then find their most engaged users are the ones getting a consistency insight, and their phone-only half were never served at all.