A kill switch
two people have to pull.
A shutdown control needs two properties that pull against each other: instant when you need it, and impossible to trigger casually. A low threshold on mobile devices gives you both.
Fast and deliberate at the same time
Kill switches tend to sit at one of two extremes. Either a single engineer can trigger one from a terminal, in which case a misread dashboard at 3am takes down a healthy service — or the shutdown requires escalating to someone senior, in which case the useful window has closed by the time anyone answers.
Requiring a small number of approvals from people already on call resolves the tension. Two of the four engineers awake tapping approve is quick, and it means the shutdown reflects a shared read of the situation rather than one person's panic.
Typical shutdown actions
Each is a separate action with its own threshold. Revoking all sessions is a bigger decision than turning off one feature flag, and the thresholds should reflect that.
- Disable a feature flag globally — the least destructive and most common.
- Suspend a payment or payout processor when fraud is suspected.
- Cut off a third-party integration that has started behaving badly.
- Revoke every active session during a suspected credential compromise.
- Halt a job queue or scheduled worker that is corrupting data as it runs.
The reason field matters more than you expect
Whoever raises the request types why. That text is signed along with everything else, so it becomes part of the permanent record — and more immediately, it is what the other approvers read on their lock screen while deciding.
In practice this is the highest-value part of the flow. "Fraud spike on card payments, 400 declines in 2 minutes, killing the processor" gives an approver enough to act on in five seconds. It also makes the post-incident review straightforward, because the reasoning was captured at the moment of the decision rather than reconstructed afterwards.
Common questions
How fast is it in practice?
Members are notified on their phones as soon as a request is raised, and approving is a tap plus a device unlock. The limiting factor is how quickly people look at their phones, not the system.
What if the shutdown needs to happen and approvers are unreachable?
Match the threshold to your realistic on-call overlap rather than your headcount. Two of four is reachable at any hour for most teams; four of four is not.
Can we have several kill switches with different thresholds?
Yes. Each action is configured separately, with its own threshold, its own webhook, and optionally its own list of members allowed to raise it.
Put a threshold on it.
Define the action, pick how many approvals it needs, point it at your webhook. Free while we're getting started.
Log in & get startedIntegrating? The full webhook contract is in the docs.