Trigger: weekly check; any cron change; any automation misfire. Owner: Jonny Allum. Policy anchors: POL-01 (secret-guarded endpoints), POL-12 (consent in automated sends).
1. The live lines (13/07/2026 — 10 routes)
Weekly digest · policy chase-ups · overdue-invoice chase · deal reminders · escalation rules · appointment reminders · recurring invoices · social publishing · bank sync (F09) · O11 integration weekly (20 6 * * 1).
All run from VM cron hitting secret-guarded API routes (BIZOS_CRON_SECRET). This table is updated in the same PR as any cron change — a schedule the SOP doesn't know about is a defect.
2. Rules for automated lines
- Idempotent by design — a double-fire must not double-send or double-create (anchored schedules and dedupe keys are the pattern).
- Secret-guarded, always — a new cron route ships with the guard, and test-firing uses the secret (never a bypass flag).
- Anything that emails/messages humans respects consent and suppression (POL-12) and writes an audit event (C05) — chases and digests must be explainable to the tenant they touched.
- New line ⇒ test-fire live once, watched (the O11 line's 12/07 test-fire is the pattern), then added to §1 and to the weekly check.
3. Weekly check (Monday, 10 minutes — after the digest window)
- ☐Monday digest: written per tenant and emailed (spot-check one tenant)
- ☐VM cron log: every line fired at its scheduled time, all 2xx
- ☐Overdue/recurring invoice lines: counts sane vs last week (a sudden spike or zero is a symptom either way)
- ☐Bank sync (F09): feeds current, no stuck connections
- ☐Any failed line: re-fire manually with the secret; if it fails twice, it's a P2 (SOP-05)
4. Runaway automation
An automation sending wrong or excessive output is contained by disabling its cron line first (SOP-05 §1), then fixed. After any misfire that reached customers: who received what, a correction/apology where warranted, and the idempotency gap closed before the line is re-enabled.