The Things task 'Automation health: N job(s) didn't run' has re-fired 36 times since 8-28. The failing checks are backlog counts (device docs over budget, docs untagged more than 4 days), not jobs that failed. Today: why an alarm you skip protects nothing, and what shape the fix takes.
On 9-21 the git sweep genuinely failed and its line sat inside the same task as two counts you had learned to ignore. The 9-23 audit calls this A1. A real failure disappearing into a familiar task is the worst outcome an unattended system can produce.
The 11:00 health check writes one FAIL line per check to job-health.log and rolls every FAIL into one deduplicated Things task. Dedup is right for a repeating fault. It is wrong when two different kinds of thing share the task: 'a job did not run' (act now) and 'a backlog is over budget' (a to-do you already know about).
This week's log: device-doc-count failed all seven days (107 docs, budget 70), waiting-rot failed all seven (FOR REVIEW docs untagged over 4 days, which is your reading pace, not a fault), plaud-ingest failed twice because its 2-hour threshold equals its 2-hour run interval, so it trips whenever the check lands first. Only the 9-21 git-sweep line was a job that did not run.
The fix shape, from audit batch 2: split the to-do checks into their own quiet task or drop them from the alarm; set plaud's threshold above its interval; and add heartbeats for the eleven jobs nobody checks. Then a FAIL task means something ran wrong, every time it appears.
Count which checks fail, and how often, over the log's history.
grep FAIL /Users/tom/Claude/PDB/logs/job-health.log \
| cut -c22-60 | sort | uniq -c | sort -rn | head
python3 -c "import json;d=json.load(open('/Users/tom/Claude/PDB/data/alert-state.json'))
for k,v in d.items(): print(v['count'], k)" | sort -rn | head -5An alarm that fires every day is a to-do list wearing a siren.