How Many Days Does a Wearable Need to Learn Your Baseline? Two to Four Weeks, and Longer Is Not Always Better

Almost every useful wearable feature compares today with “your normal”. A readiness score, an elevated heart rate alert, a “you slept less than usual” card: each depends on a personal baseline, and each is only as good as that baseline.

So how many days does a baseline need? The wearable makers give different answers. Apple asks for 7 nights, Oura up to two weeks, Garmin about three weeks. Published research does not settle it either. So we simulated it, using the day-to-day variation measured in large wearable studies. The answer is a trade-off rather than a number: short baselines raise false alarms, long ones take weeks to accept a real change. Between them is a range that works, and a set of rules that make baselines dependable at any length.

How many days does a wearable need to learn your baseline?

Two to four weeks is the practical range, and the major platforms sit inside it:

The differences are not arbitrary. They follow the noise in what each feature measures.

Why does HRV need longer than resting heart rate?

Because it is far noisier from night to night. Across 92,457 Fitbit users, resting heart rate varied by an average of about 3 bpm day to day within the same person, around 5% of a typical value [5]. Nightly HRV moves much more: in a WHOOP study of elite athletes, the weekly coefficient of variation of log-transformed RMSSD averaged 5.4% [6], which corresponds to night-to-night swings of roughly 20% to 25% in RMSSD itself, about five times the relative noise of resting heart rate.

A noisier signal needs more nights before its average means anything. That is why Garmin waits about three weeks for HRV Status, while a resting heart rate trend can be useful sooner.

How precise is a 7, 14, 28 or 60-day baseline?

A baseline is an estimate, and its uncertainty shrinks slowly. Assuming consecutive days resemble each other, with a day-to-day correlation of 0.5, the 95% range of a baseline’s average is:

After a week, a resting heart rate baseline can be off by nearly 4 bpm, which is more than most of the changes it is meant to detect. If days were fully independent the ranges would be narrower, ±0.74 SD at 7 days, but real wearable data is correlated: a poor night tends to follow a poor night.

How many false alarms does a short baseline cause?

We simulated the simplest alert rule, “flag today if it is more than two standard deviations above the baseline”, which should flag about 2.3% of normal days. With a short baseline, both the average and the spread are poorly estimated, so it flags far more:

A product that alerts from day 7 will tell a perfectly healthy user something is wrong about every other week. Users learn to ignore alerts faster than they learn to trust them.

Why can a longer baseline be worse?

Because people change, and a long baseline keeps treating the change as unusual. We simulated a lasting shift of one standard deviation, about 3 bpm of resting heart rate:

A shift of that size is ordinary. Starting a GLP-1 raised resting heart rate by about 2 to 3 bpm in the SURPASS-2 trial [7]; population resting heart rate is about 2 bpm higher in early January than in late July [5], as we covered in why step counts drop in winter; and switching device changes the measurement itself, one of the data quality checks worth running. With a 60-day baseline, any of these keeps a user looking “unusual” for six weeks.

That is the trade-off in the figure above. Around 14 to 28 days, false alarms are close to the intended rate and a lasting change is absorbed within two to three weeks. Shorter windows cry wolf; longer ones refuse to accept a new normal.

How should a product handle baselines?

1. Do not alert before about 14 days. In the first two weeks, show values with population context and clear “still learning” labelling, which we covered in cold-start personalization.
2. Use 14 to 28 days for daily comparisons, and pair it with a longer reference, 60 to 90 days, for slow drift. Oura’s approach, short weighted averages compared against a longer-term baseline, follows the same logic [2].
3. Require persistence. In our simulation, flagging only when two of the last three days exceed the threshold cut false alarms from 6.3% to 3.6% of normal days, about 40% fewer, while catching nearly as many real changes: 41% against 42% for a 1.5 standard deviation change lasting three days.
4. Use medians, not means, so one bad night or one sensor glitch does not move the baseline, and leave out days already explained: illness, long-haul travel and the night the clocks change.
5. Reset or segment when the measurement changes: a new device, a firmware update that changes an algorithm, or the start of a medication known to shift heart rate.
6. Show how many days the baseline is built on. “Compared with your last 9 nights” is honest; “compared with your normal” after 9 nights is not.

A minimal version of rules 3 and 4:

from statistics import median

def robust_baseline(values):
    """Median and scaled median absolute deviation of the baseline window."""
    m = median(values)
    mad = median(abs(v - m) for v in values) * 1.4826
    return m, mad

def is_unusual(history, recent, window=21, k=2.0, need=2):
    """Flag when at least `need` of the `recent` days sit k spreads above the baseline."""
    if len(history) < 14:
        return False  # still learning
    m, spread = robust_baseline(history[-window:])
    return sum(v > m + k * spread for v in recent) >= need

A personal baseline is the foundation of almost every personalised wearable feature, and it is easy to get wrong in both directions. Too short, and the product cries wolf. Too long, and it refuses to accept that the user has changed. Two to four weeks, a rule that asks for persistence, and honest labelling of how much data is behind each comparison get most of the way there.