---
title: "A Live Dashboard That Only Refreshed for Pages Left Open"
canonical: https://dxdev.com/blog/2026-09-12_refresh-gate-served-open-pages-only/
datePublished: 2026-09-12
---
I asked for a look at what had closed out recently and got an answer that was two and a half days old. The status page behind it is supposed to update within seconds. Instead the data I was looking at had been generated two mornings earlier and only covered two of the days since, while real, closed work had piled up on top of it the whole time.

The obvious question was whether the background watcher itself had died. It hadn't. Its own heartbeat was healthy and its log showed it stepping its own polling cadence up and down all evening, exactly as designed: check every few seconds right after something happens, then back off to checking every fifteen seconds, then a minute, then five minutes, then finally every fifteen minutes once things go quiet. A perfectly healthy process, watching, on a cadence that gets slower the longer nobody's around.

## Healthy watcher, broken gate

The bug wasn't in whether the watcher was running. It was in what decided whether the watcher actually rebuilt the snapshot on a given pass. That decision came down to one check: had something asked for a refresh inside the last several seconds. A page left open keeps re-asking every few seconds on its own, so it almost always lands inside that short window whenever the watcher happens to check.

A single one-off request, the kind a script or a tool sends once and then stops, asks exactly once. Unless the watcher's own loop happened to wake up within that same short window, the ask was already stale by the time the next check came around, and once the watcher had backed off to its slowest cadence, the next check might not come for fifteen minutes. Do that enough times in a row and a snapshot that is supposed to be seconds old can sit for days with nobody the wiser, because nothing about the watcher itself ever looked broken.

## Where the gate came from

That check hadn't been written for this feature from scratch. It was copied, on purpose, from an existing check built for a different page, one that behaves like a dashboard someone tends to leave open, where "asked in the last few seconds" is a safe proxy for "someone is actively looking at this right now." That assumption holds for a page that keeps re-touching the flag every few seconds by itself. It does not hold for a feature that also gets asked one-off questions by scripts and automated tools rather than a person watching a tab, and nothing distinguished the two cases in testing, because both look identical right up until a request goes unanswered for long enough that someone actually notices.

## The fix

The gate needed to stop asking "was I asked recently" and start asking "has anything asked since I last actually refreshed." That's a comparison between two timestamps, when the last ask came in and when the last refresh happened, not a moving window that can expire before the watcher gets around to checking it. Whatever cadence the watcher happens to be on when it wakes up next, fast or slow, it now catches up on any pending ask exactly once and goes quiet again. Worst case staleness becomes one full idle sleep, never open-ended. The original window check didn't go away. It kept its narrower, correct job of deciding whether the watcher should speed its own cadence up because someone is actively around, it just stopped being the thing that gated whether a refresh actually happened.

I added tests for the specific edge this exposed: an old, already-served ask does nothing on its own, a fresh ask gets served exactly once no matter how long it had been waiting, and no ask on record does nothing. Then I checked it against the real, currently running process rather than trusting the tests alone: touched the ask flag, waited about twenty seconds, and confirmed the live watcher, already running the fixed code since it restarts itself whenever its own source changes, rebuilt the snapshot on its very next cycle.

While I was in that part of the code I also found a small stray file, a crash artifact from an unrelated tool, that had been sitting tracked in the repository for weeks without anyone noticing it was there. Different bug, same shape: something got written once, nothing was watching for it afterward, and it just sat there being true and stale at the same time. I removed it in the same pass.

Whole thing, diagnosis through a verified production fix, took about thirty-eight minutes, most of it spent reading the gate rather than rewriting it. A watcher that's alive and a feature that's actually working are not the same claim. The second one needed proving against the case where nobody was watching, not the case where someone almost always is.