A kill-switch is not pessimism. It is an admission that markets change and systems break. The mistake is improvising stops after pain, when you are least rational.

Tier 1: execution and operational triggers

Stop or reduce automatically when:

average slippage exceeds your validated baseline for N trades
missed orders or API errors spike
latency crosses a threshold that invalidates your entry model

These triggers protect you from "the strategy is fine, the plumbing is not."

Tier 2: economic performance triggers

Examples:

rolling 30-day expectancy below zero after a minimum sample
drawdown beyond a pre-agreed budget
profit factor collapse versus OOS expectation (not versus the best IS window)

Write numbers in advance. If you wait for feelings, you will move goalposts.

Tier 3: model invalidation triggers

Stop when assumptions break:

liquidity collapse on traded pairs
structural market changes (listing changes, margin rules, contract migrations)
your data vendor changes feed composition

How to avoid false stops

Use hysteresis: require triggers to persist for multiple observations, not one bad hour.

Runbook: what happens in the first 60 minutes after a trigger

Write this in advance:

who can acknowledge the alert
whether the default action is reduce size or full flat
how you capture logs and trades for postmortem
when you are allowed to re-enable (explicit checklist, not vibes)

Most damage happens in the gap between "something looks wrong" and "someone decides."

Separate human panic from automated stops

Automated stops should be dumb and fast. Human review can be slow and careful.

If your automation waits for a human on every spike, you do not have a kill-switch. You have a pager.

Test the kill-switch quarterly like a fire drill

Run a tabletop exercise: simulate a feed gap and confirm the bot actually pauses as designed.

Most "kill switches" fail the first time they are needed because nobody tested the wiring.