What makes a kill switch real?

Somebody other than its author can reach it, it has been pressed at least once outside an emergency, and there is a defined answer for what happens to the work that was in progress. Missing any of the three leaves a control that exists on paper.

Should it stop or pause?

Both are worth having. Pausing holds new work while the current item completes, which suits anything transactional; stopping is for when the item in progress is itself the problem. Choosing between them during an incident is the wrong time to think about it.

What about restarting?

It deserves the same thought as stopping and rarely gets it. A system brought back with everything that queued up while it was off can reproduce the original problem faster than it happened the first time, so the restart needs a rule about what to discard.

Glossary

Kill switch

A single control that stops an automated system immediately, useful in proportion to who can reach it and whether anybody has tried.

In plain terms

A way to stop the thing now. Three questions decide whether you have one: can somebody other than the person who built it reach it, has anybody ever pressed it, and what happens to the work that was halfway through when they do.

Why it matters

Because it is the control that makes increasing autonomy a reversible decision. Without one, every expansion of what a system may do is a bet that nothing will go wrong, and with one it is an experiment you can end.

How it works

Reachability is the first test and the one most often failed. A switch that requires the person who built the system, or access to a console only one team holds, does not exist at three in the morning, which is when it will be wanted.

It has to have been pressed. An untested stop is a belief, and the usual discoveries on first use are unglamorous: it stops one component while another continues, or it needs a credential nobody on the shift has.

Work in flight is the part nobody designs. Stopping mid-action can leave a record half-updated, a message partly sent or a queue half-drained, so a stop needs a defined answer for what happens to whatever was in progress.

There is a difference between stopping and pausing, and both are worth having. Pausing holds new work while letting the current item finish, which is safer for anything transactional; stopping is for when the current item is the problem.

Restarting deserves as much thought as stopping. A system brought back with a queue of work that accumulated while it was off can repeat the original problem at speed, so the restart path needs its own decision about what to discard.

It belongs in place before autonomy increases, not after. The natural sequence is to widen what a system may do and add controls when something goes wrong, and reversing that order costs almost nothing at the start and everything once the incident has begun.

Three questions that decide whether you have one

The third line on the right is the one that turns a good control into an incomplete one, and it is the least intuitive. Stopping feels like returning to safety, and for a system that only reads or drafts it more or less is. For anything that changes records, sends things or moves money, stopping mid-action leaves whatever was underway in an undefined condition, and the person who pressed the switch now owns a second problem they did not have a minute earlier. The fix is not technically demanding: decide in advance whether a stop lets the current item finish or abandons it, make sure whoever might press it knows which, and write down where to look for anything that was interrupted. Doing that once, calmly, is the difference between a stop that ends an incident and one that changes its shape. It is also the part that never appears in a design review, because the reviewer is asking whether a kill switch exists rather than what happens after somebody uses it.

Seen in the wild

An agent that can be stopped by whoever is on shift rather than by whoever built it.
Lindy
An automation paused so the item in progress completes while nothing new starts.
Make
A stop that leaves records half-updated because nothing defined what in-flight work meant.
Zapier

Common misconceptions

People assume

We have one because the system can be switched off.

In fact

Being able to switch something off is not the same as having a control somebody on shift can reach, has used before, and knows the consequences of. The first is a fact about the software; the second is what you need at three in the morning.

People assume

Stopping returns things to a safe state.

In fact

It stops the system where it stood, which may be halfway through something. Without a defined behaviour for work in progress, the stop can leave a partly-updated record that is harder to deal with than the original problem.

Questions

What makes a kill switch real?: Somebody other than its author can reach it, it has been pressed at least once outside an emergency, and there is a defined answer for what happens to the work that was in progress. Missing any of the three leaves a control that exists on paper.
Should it stop or pause?: Both are worth having. Pausing holds new work while the current item completes, which suits anything transactional; stopping is for when the item in progress is itself the problem. Choosing between them during an incident is the wrong time to think about it.
What about restarting?: It deserves the same thought as stopping and rarely gets it. A system brought back with everything that queued up while it was off can reproduce the original problem faster than it happened the first time, so the restart needs a rule about what to discard.