Dead man's switch — catching the job that vanishedConcept

Your failure alerts only fire when a job runs and crashes. When a job never really starts — or dies before it can report — the cadence just vanishes. The fix is a dead man's switch: a separate checker that asks 'did the artifact show up?' instead of trusting the job to announce its own death.

All your alerting so far is *self-reporting*: run_plan_day.sh catches its own errors and files a 🚨 Things task; the alert ledger (Jul 21) dedups those reports. But self-reporting has a blind spot — the reporter and the failure are the same process. If claude -p can't even reach its API (ConnectionRefused), the code that would have filed the alert dies with the job. The job doesn't fail loudly; it simply leaves no trace.

A dead man's switch inverts the question. Instead of 'did anything report a failure?' it asks 'did the expected *evidence of success* appear on time?' Railway engineers built this into locomotives a century ago: the driver must actively hold a lever; if the hand disappears, the brakes fire. No signal IS the signal. In software the pattern is called a heartbeat or witness check: a second, dumber process that knows only two things — where job X leaves its artifact, and how stale that artifact is allowed to get.

The witness must be *simpler and more reliable* than the thing it watches. Your weekly review depends on Claude, OAuth tokens, and the network — three ways to die. A witness needs only `find -newermt` and the Things URL scheme, which is exactly the deterministic-local-script layer CLAUDE.md already prescribes for verify-and-send. You even have a natural home for it: app.zorc.job-health already runs on a schedule — teaching it to check artifact freshness turns it into the witness for every cadence at once.

Worked example

The whole pattern is one shell test. Run it right now against the real weekly-review ledger:

# Did the weekly review leave its companion record in the last 8 days?
find /Users/tom/Claude/PDB/planning-history \
  -name 'weekly-review-*.md' -newermt '8 days ago' | grep -q . \
  && echo "OK — review ran this week" \
  || echo "MISSING — no weekly-review artifact in 8 days"

# Backdate the check to Jul 20 and the silent month lights up:
find /Users/tom/Claude/PDB/planning-history \
  -name 'weekly-review-*.md' -newermt '2026-07-12' \! -newermt '2026-07-20' | grep -q . \
  || echo "MISSING — this is what Jul 20 would have caught"

• find -newermt '8 days ago' lists files modified in the window; grep -q . just asks 'was there at least one?' — the file's existence is the heartbeat, no log parsing needed.
• 8 days, not 7: the review fires Sundays at 18:00, so a 7-day window run on Sunday morning would false-alarm every week. Always pad the window past the cadence.
• The second command replays history: between Jul 12 and Jul 20 no artifact landed — a witness running that week would have filed a 🚨 task while the actual job died three times in silence.

Gotchas

• Don't put the witness inside the job it watches — same process, same blind spot. It must be a separate LaunchAgent (or a line in job-health).
• Check the artifact, not the log. Logs grow on failure too; only the *success artifact* proves the work happened. (Automation-hygiene rule #1: verify the side-effect, not the trigger.)
• A witness that alerts nowhere is decoration. Its failure branch must call things.add_task(..., tags=['🚨'], when='today') — the one channel you actually read.
• Pad the freshness window past the cadence (8 days for weekly, 26 hours for daily) or you'll cry wolf on schedule jitter and start ignoring the 🚨 tag — which kills the whole alert channel.