The kill switch is a per-store flag you own (stores.config.kill_switch). It's off by default — normal operation doesn't need it. Flip it on and every worker job that writes or spends refuses to start, logged as a skipped run. But 'everything stops' is the wrong mental model, and the difference matters when you're deciding whether to press it.
What freezes
- Every job that writes or spends, across every agent. No catalog writes, no bid changes, no CS sends, no feed pushes — each refuses to start and appears as a skipped run in the job log.
- Anything that was applied just before the freeze stays fully auditable and revertible afterwards — the revert executor works from the logged rows.
- Scheduled work still ticks, but every write cycle checks the flag before doing anything and stands down.
What keeps running
- Data ingestion — orders, metrics, and mailbox sync keep flowing, so you're not blind when you flip back on.
- Reporting — dashboards stay live on current data.
- Alerting — anomaly checks and notifications still fire. If the thing that made you press the switch gets worse, you'll know.
- The audit log — the skipped runs are themselves logged, so the freeze leaves a record.
Eyes on, hands off
That split is the design: hands off, eyes on. The kill switch removes the system's ability to act without removing your ability to see. If it also silenced monitoring, pressing it during an incident would trade one risk for another. It doesn't. You freeze the writes and keep the full picture while you diagnose.
Drill it monthly
A switch you've never pressed is a hope, not a control. Once a month, on a normal day: press it, confirm new write jobs refuse to start (they appear as skipped runs), verify anything in flight was stamped in the log and is reversible, flip back on. Five minutes, and the muscle memory is real when you need it.