An alert that fires 13 times is a to-do, not an alertReview

Review week. The alert ledger dedups repeated failures into one task with a rising count, which stopped the noise and quietly removed the pressure to fix. 'Automation health: 4 jobs didn't run' has been open since 8-28 with count 13.

PDB/data/alert-state.json is written by connectors/notify.py. alert(title, body, dedup_key) hashes the failure into a signature; if that signature is already open it updates the existing Things task and bumps 'count' instead of filing a new one. resolve(key) closes it when the condition clears. This is the right design: without it, the 11:00 health check would have filed thirteen identical tasks.

The failure mode is the flip side. A deduped alert is easy to dismiss because it is always the same task, and a count of 13 reads as 'known'. Look at the four: learning-runway is fixed by the weekly review's pre-render leg (this very week). device-doc-count and waiting-rot are one problem with one owner (you, via D2 on the 9-6 paper). plaud-ingest expects a run every two hours and the recorder simply is not used that often. Three of four are threshold or ownership questions, not outages.

The rule to carry forward: any deduped alert with count above five needs one of three marks. Fix (someone owns it by a date), raise-threshold (the expectation was wrong), or accept (silence it deliberately, in writing). The weekly review is the place to make that mark, because it is the only recurring surface where you and the ledger meet.

Worked example

Read the ledger and triage it in one pass:

python3 - <<'PY'
import json
for k,v in json.load(open('/Users/tom/Claude/PDB/data/alert-state.json')).items():
    print(f"{v['count']:>3}  {v['opened_at'][:10]}  {k}  |  {v['title']}")
PY

grep -n 'plaud-ingest' /Users/tom/Claude/PDB/scripts/job_health_check.py | head -3

• One line per open alert: count, opened date, key, title. Sort by count in your head; the top one is the oldest unanswered question.
• The second command finds the plaud-ingest expectation (under two hours). Whether that is the right number is a threshold decision, not a bug.

Gotchas

• Resolving an alert by deleting the Things task does not clear the ledger; the next check re-files it. Use notify.resolve or fix the condition.
• Raising a threshold to make red go green is legitimate only if you write down why. Otherwise it is the 8-20 false-green in a new coat.
• Two of the four alerts share a cause. Fixing the device backlog clears both. Count the causes, not the lines.