Missing history drives repeated checking for updates

What it is

Without replayable history, people cannot confirm "did it already come, did I miss it." The uncertainty does not rest. It becomes repeated app opens, pull-to-refresh, empty scans of the shade—not because there is new work, but because "I missed it" cannot be falsified. One job of history is to make absence visible: I looked, it is not there, I can stop.

This is how missing history manufactures a checking loop. It is not how a badge numeral promises pending work, and not how clocks are ordered once items are in history.

Why it happens

Checking is behavior that reduces uncertainty. If notices only live briefly in the shade, uncertainty peaks after they vanish: maybe it came, maybe it didn't, maybe it was swiped. Opening the app samples with a session. If the sample still cannot close "what happened in this window," the next interval shortens. The loop spends attention that belonged to the primary task, and trains opening the app as soothing rather than as "there is work."

With history, "nothing" is an observable state: a list, a time range, empty. An empty list is better evidence than an empty shade, because an empty shade may have been cleared.

Studying it

Send sparse notices over a stretch of time, with history versus without. Count app opens, pulls, and shade summons when nothing new has arrived, plus self-reports of fear of missing.

Independent variables: history present, whether empty state names a time range, whether the shade auto-clears. Dependent variables: check count with no new arrivals, interval between checks, primary-task cuts.

Lab sessions are too short for checking to form. Use multi-day diaries or the share of product sessions that open to no new content. High opens are not engagement—they may be anxious sampling.

Where it stops holding

Workbenches that are supposed to be checked often (trading, support queues) treat checking as the job; missing history is not the main driver—though an arrival log still reduces "refresh to see if the API is dead." If history itself is unreachable offline, checking moves to retrying the connection; show the last-sync time from cache. For tools that almost never notify, the loop is weak and a full replay need not come first.

Applying it

• Offer openable history whose empty state says "no notices in the last N hours," so absence is visible.
• Do not auto-clear the shade into nowhere; clears should enter history.
• A cold start born of "did I miss something" should be answerable from history, not from a blank home.
• Verify with two notices in a day and hours of gap. If the no-history group still opens the app repeatedly in the gap and finds nothing, the loop is running; adding empty history with a time range should drop those gap opens. If opens fall and the two real arrivals are still handled, what left was checking, not work.

Related

• Within the group: H5.11.1 Dismissed notices must be replayable in history · H5.11.2 History must keep original timestamps, not reorder by time of viewing · H5.11.3 Items held during do not disturb must merge into history, not vanish
• Adjacent: H5.05 Badges and unread counts · H5.03 Do not disturb and focus · H5.07 Push frequency
• Search terms: checking habit · fear of missing · empty history