Check liveness by the data, not by the code

Switched on and actually writing data are two different claims, and only the data can settle the second one.

Why it matters

A silent watcher looks identical in two completely different situations: there really are no events, or the watcher died long ago. From the outside you cannot tell.

And it dies quietly. A dropped database connection, a restart, a flag left off, a renamed field in somebody else's response — any small thing, and the data stops being written. Nobody notices, because the only symptom is silence. And silence is what you expect.

How it's done

Don't ask the code whether it's running. Ask the data when the last write happened.

For that, every watcher needs a timestamp it refreshes on every pass — even when there are no events. Then "no events" and "watcher is dead" become two different states: in the first the stamp is fresh, in the second it's stale.

Then put that on the page: every number carries its time. If the time is old, the number goes dim by itself and the reader doesn't have to guess.

What usually comes out

That some of the watchers everyone assumed were running have been frozen for months. Sometimes the opposite: a watcher everyone assumed was switched off is dutifully writing data nobody reads.

A comment in the code is the worst possible source of truth about the state of a system. It describes what the author was thinking when they wrote it, not what is happening now.

What this does not tell you

A fresh timestamp says the process is alive, not that it's collecting the right thing. A watcher can dutifully write garbage — that's a separate check.