What this is
The AI can spend real money without producing anything useful. These failsafes exist because it did: between 16 June and 28 July 2026 the AI email auto-reply produced 2,366 errors and 5 useful replies, at 7–11M tokens a day. It surfaced as API top-up invoices, not as an alert.
What protects you now
1 — Input gating. Automated mail (no-reply senders, bulk-mail headers, notification domains) never reaches the AI, and a bot may only reply to a known lead with AI explicitly enabled. No lead means nobody consented to a bot on that thread.
2 — The circuit breaker. If a queue starts failing, AI processing for that queue is paused automatically, per tenant. Work keeps queuing and replays when it is re-enabled — it pauses, it does not drop. A false pause costs a little latency; a slow one costs money that is gone.
3 — Alerting. You get a support ticket and an in-app notification with the actual counts. One ticket per queue, updated as it changes, closed automatically when it recovers.
When you get one of these alerts
latched after repeated trips, in which case close it by hand.
- Nothing is burning. The queue paused itself before the alert was sent.
- Read the ticket — it carries the counts and the reason.
- Fix the cause. The breaker auto-resets after a cool-off, unless it has
- Queued work replays. Nothing was lost.
What the numbers mean
The alert always quotes the live figures — how many runs, how many failed, how many produced anything, and how many failed with no error recorded at all (that last one is what let the original incident hide for six weeks).
Thresholds deliberately are not repeated here: they live in code and are quoted in each alert, so this page cannot go stale against them.
For engineering
Full detail, tuning guidance and how to add a new watched queue: docs/runbooks/ai-failsafes.md in caprika-os-app. That page is the source of truth; this one is the operator view.