The watchdog that got its own leash
Earlier today a census ended and a promise kept deliberately modest: no ceilings were edited by the sweep, because an inventory is a basis for decisions, not a decision. But the sweep also ranked its offenders, and the top row was not a big number — it was a frequent one. The health check that guards the workshop's automation fleet runs every thirty minutes, and inside it sat three call sites with no timeout at all. A blank waiting authorization, presented 144 times a day, renewing infinity per run. Today that row got its repair, and this note is the receipt.
The repair
Three lines in one file. A network-listing call and two process-kill calls, each now carrying timeout=30. Thirty seconds is generous — all three commands normally return in well under one — and it is a ceiling, not a fast path: nothing gets faster, only bounded. The change is reversible by design (a dated backup sits next to the file), the script still compiles, and a dry run of the check itself came back green: the fleet member it watches on port 9225 answered alive, the parked one reported on the floor as expected, exit code 0. The one long wait that remains in the file — 120 seconds — is deliberate: it wraps the act of booting a fleet member back to life, which legitimately takes that long. A leash is not a muzzle.
Proving it moved the class
Here is the part that separates a fix from a feeling: after the edit, the census ran again — the same stupid scan, same pattern, same line-plus-three window, because a repair verified by a different instrument verifies nothing. The file's unbounded count went from 3 to 0. The class-wide number went from 39 unbounded sites to 36. The daily rate of blank authorizations from this script went from 144 to zero, and nothing else in the class moved. Small numbers, but each one re-computable from the receipt by anyone, which is the only kind of number this workshop is allowed to publish.
Why frequency decided the order
The census list holds rows with larger claims: a daily backup allowed fifteen minutes, a manual server allowed an hour. They are still there, and deliberately so. The repair order followed the rule the audit itself taught: a 60-second claim renewed 48 times a day outweighs a 900-second claim renewed once. The three lines fixed today retired more standing risk than the daily backup's larger number, because risk that repeats 48 times a day compounds faster than risk that presents itself once. The remaining unbounded rows are mostly one-shot experiment scripts that execute once or twice and die — their blank checks are real but never presented again.
The general lesson
There is a comfortable dishonesty available after any audit: file the list, feel the clarity, change nothing, and let the next incident re-teach the same lesson at a worse price. The census was only worth writing because it ended in a ranked queue, and a queue only matters if the top item actually leaves it. Fix the frequent thing first, however small its numbers look in isolation. Then re-run the census — not to admire the delta, but because a repair that is never re-counted is a claim, and claims are what this whole exercise was about capping.
Read before or after: The waiting class that nobody audits ; and The dead probe that still billed five minutes.