§1The vacuous pass
A scheduled check watched a purchase funnel: were there errors, were steps failing, was completion falling. It ran every morning and it reported healthy every morning, long after the funnel it watched had been removed from the product entirely.
Nothing malfunctioned. Every assertion was evaluated honestly and every one returned true. There were no errors because there were no requests. No step was failing because no step existed. The monitor was not lying about its measurements; it was answering a question that had stopped being meaningful, and formatting the answer as reassurance.
An empty set satisfies almost any safety condition you write about it. “No failures were observed” is trivially true when nothing can be observed at all.
§2“No failures” is not “healthy”
Most monitors are built to answer one question: did anything break? Very few are built to answer the prior question: does the thing I watch still exist, and is it still doing enough for my measurements to mean anything?
Without that second question, absence and health produce identical output. The daily green becomes evidence of nothing, and worse, it consumes the attention that a real signal would need. A check that cannot fail is not protection; it is a subscription to false confidence.
§3Give the monitor a liveness assertion about its own subject
The fix is small and structural: before evaluating any health condition, assert the subject. Does the page still resolve, does the endpoint still exist, did the event stream carry at least a minimum volume in the window?
If that assertion fails, the correct state is not OK. It is UNKNOWN, or better, DECOMMISSIONED—a state that demands a human decision about whether the monitor should still exist. This is the same distinction that keeps a broken collector from producing a false all-clear: unknown is not unchanged.
| Subject | Failures seen | Honest state |
|---|---|---|
| Exists, active | None | OK — the measurement means something. |
| Exists, no volume | None | UNKNOWN — nothing was exercised. |
| Gone | None | DECOMMISSIONED — retire the monitor. |
§4Deletion has a maintenance tail
Removing a subsystem is visible work: files disappear, routes are retired, the diff is legible. The watchers are not in that diff. They live in a scheduler, a cron table, a workflow runner—infrastructure that nothing in the change touches and no reviewer reads.
So they survive by default. The half-life of an orphaned monitor is measured in however long it takes someone to notice that a report has been arriving with nothing behind it, and a report that always says fine is the hardest kind to notice.
§5Name the watchers inside the change
When a subsystem is removed, its observers are part of the removal. Enumerate them in the same change that deletes the thing: which scheduled jobs, alerts, dashboards, and recurring reports name this subject, and for each one—retire, repoint, or explicitly keep with a stated reason.
The cost of doing this at deletion time is a few minutes. The cost of not doing it is a monitoring surface that slowly fills with jobs that cannot fail, which is indistinguishable from a monitoring surface that is working.
§6Audit the schedule after any removal
FOR EVERY RECURRING JOB
SUBJECT
What exact thing does this assert about?
EXISTENCE
Does that thing still exist and still carry volume?
FALSIFIABILITY
What input would make this job fail today?
If nothing can, the job is decorative.
DISPOSITION
Retire · repoint · keep with a stated reasonThe third question is the one that finds these. Any check with no reachable failure state has already stopped being a check—it just has not been told yet.
The compact rule
- An empty set passes nearly every condition you write about it.
- Assert the subject exists before you assert it is healthy.
- Absent and healthy must not produce the same output.
- Enumerate a subsystem’s watchers inside the change that deletes it.
- A check with no reachable failure state is decoration.