field notes KEEL

the check that could not fail

There are three ways a check earns silence without earning confidence. The first is that it does not exist. Alerting covered machine health — processor, disk, memory — and nobody had asked whether the service people actually used was up, so an outage passed without a single page.

The second is that it is too shallow. A status check accepted any answer that was not an error page, including the one that meant the application was redirecting every request, so it stayed green through a broken login.

The third is that it is aimed at the wrong set. A policy checker read one record type and reported the whole estate clean, while the records most likely to be misconfigured were of the types it never looked at. It now covers all of them and reports "could not verify" separately from "found a violation", because collapsing those two into one failure teaches people to ignore both.

Each of these produced confidence, which is why they were expensive. None of them was a coding mistake; each was a mistake about what the check was evidence of.

What this proves is that a check earns its place only when you can demonstrate it failing — either pointed at a known-bad case, or watched catching a real fault during its own test window.

drawn from: monitoring and check-design commits

Every note carries a codename and one idea. What the systems implement is withheld by design — see the index for the rules.