How Do You Know Wearable Data Is Wrong? 12 Checks to Run Before You Score Anything

Every sleep score, readiness score, AI coach and programme report inherits the errors in the data beneath it. A score cannot be more accurate than its inputs, and an AI model given a week with three missing nights will often describe the week anyway, as we found in how accurate AI health coaches are.

The good news is that most bad wearable data is not subtle. It fails in the same dozen ways, and each can be caught with a rule. Researchers at Duke, working with Fitbit data from the NIH All of Us programme, argue that quality control has to come before analysis, not after it [1]. These are the twelve checks we would run before computing anything, grouped by the question each answers. First, what they look like together, on one ordinary day:

What wearable data values are implausible?

1. Impossible and implausible values. A heart rate of 0 or 400, blood oxygen above 100%, a negative step count or a 20-hour sleep are not measurements. Some values are impossible and should be dropped; others are merely unlikely and should be flagged, because rare real values exist.

2. Units. The same number means different things in different units, and conversion errors look like real data. Glucose of 5.6 is normal in mmol/L and impossible in mg/dL; the factor between them is about 18. Weight differs by 2.2 between kilograms and pounds, and temperature by much more between Celsius and Fahrenheit. Platforms store units explicitly, so read them rather than assume them, and flag any value that only makes sense after an unexplained conversion.

3. Stuck and flat sensors. A heart rate that reads exactly the same for an hour, or blood oxygen fixed at one value all night, usually means a stalled sensor or interpolated filler rather than a remarkably steady body. Flag long runs of identical values, and compare them against the device’s usual variation.

4. Motion that is not walking. Wrist accelerometers can count vibration as steps, on a bumpy drive, a bus or a bike, and miss steps when the wrist is still, as when pushing a pram. Steps logged while heart rate shows the device was not worn are a clear sign; researchers working with All of Us data note that step counts can accumulate while a device sits in a bag [1]. Treat steps with no matching wear as suspect.

How do you handle duplicate, replaced and deleted records?

5. Duplicates across sources. A phone and a watch can both write steps for the same walk, and two apps can write the same workout. Apple Health’s statistics queries merge overlapping data using the user’s source priority, but raw sample queries return everything. Summing raw samples double counts. We covered how to resolve overlaps in deduplicating health data across wearables.

6. Records that replace earlier records. Some providers send the same day more than once as it fills in. Garmin’s specification says an updated summary shares the user, start time and type of the earlier one and that integrations “should replace old records with the updated summary” [4]. Appending instead of replacing inflates every daily total. Key records on user, source, type and start time and upsert them, as described in how much data one wearable user generates.

7. Deletions and edits. Users delete mistaken entries and apps revise their own data. HealthKit’s anchored object query returns deleted samples as well as new ones [5], and Health Connect exposes changes the same way. A pipeline that only ever adds data keeps the mistakes after the user has fixed them. Mirror deletions and recompute what depended on them.

8. Manual and app-written entries. A weight typed in by hand, a workout logged after the fact and a value written by a third-party app are not sensor measurements. HealthKit marks user-entered samples with HKMetadataKeyWasUserEntered [6], and Health Connect records whether data was entered manually, recorded automatically or recorded during an active session [7]. Keep manual entries, but label them, and decide deliberately whether they belong in automated baselines.

How do you handle time zones and late-arriving data?

9. Time zones, clock changes and impossible timestamps. A record without a time zone cannot be placed on the user’s day; a record with only local time cannot be placed in absolute time. Clock changes create 23- and 25-hour days. Device clocks drift and produce data from the future. Check for missing offsets, end times before start times and timestamps ahead of the time of receipt, and run the clock-change tests in daylight saving time and sleep data.

10. Late arrivals. Wearable data often reaches the cloud hours or days after it was recorded, when the user next syncs. A day finalised at midnight will be wrong when the rest of its data arrives. Hold days open until data has had time to arrive, recompute when late data lands, and see why wearable data is late for how long each source typically takes.

How much wear time makes a valid day of data?

11. Wear time. A day with three hours of data is not a low-activity day; it is an incomplete one. A common research rule counts a day as valid with at least 10 hours of data, and a week as valid with at least three valid days [1]. Researchers recommend measuring wear as the share of minutes with heart rate data, because devices record heart rate only when worn [1]. Missing data is substantial even on a worn device: in one comparison, Fitbit’s heart rate was missing 18.7% of the time at rest [1]. Score only valid days, show coverage alongside every value, and be wary of filling gaps, since people take devices off when they are ill, travelling or charging.

Why do HRV, calories and sleep differ between devices?

12. Same name, different metric. The most expensive errors are values that look comparable and are not:

Detect device and source changes from record metadata, and restart or segment personal baselines when they happen, rather than reading the jump as a trend.

What should you do when a data check fails?

Every failed check should end in one of four actions, recorded with a reason, never in a silent fix:

A simple way to start is a rules table that every incoming value passes through:

RULES = {
    "heart_rate":  {"unit": "count/min", "error": (25, 250)},
    "spo2":        {"unit": "%",         "error": (0, 100),   "flag_below": 80},
    "steps_daily": {"unit": "count",     "error": (0, None),  "flag": (100, 50_000)},
    "sleep_hours": {"unit": "h",         "error": (0, 24),    "flag": (0.5, 16)},
}

def check(metric, value, unit):
    rule = RULES[metric]
    if unit != rule["unit"]:
        return "unit_mismatch"
    low, high = rule["error"]
    if value < low or (high is not None and value > high):
        return "drop"
    if "flag" in rule and not rule["flag"][0] <= value <= rule["flag"][1]:
        return "flag"
    if "flag_below" in rule and value < rule["flag_below"]:
        return "flag"
    return "ok"

The thresholds above are starting points, not clinical standards. Tune them to your population, log every non-ok result with its reason, and track the share of each user’s days that pass, because a falling pass rate is often the first sign that a source has changed underneath you.

None of these twelve checks is sophisticated. That is the point. The errors that most often break health scores are not deep modelling problems but wrong units, double counts, replaced records, missing wear time and two metrics with one name. Catching them is cheap, and it is the difference between a score users trust and one they learn to ignore.