A kill switch is a long-lived operations flag that lets operators turn off or degrade a feature quickly during an incident, without a redeploy. A good one has a named owner, a tested off state, a safe default if the flag service is down, and a limited set of people who can flip it.
What the term means
Martin Fowler describes kill switches as long-lived ops toggles that let operators gracefully degrade non-vital system functionality, for example under heavy load. He also notes that operators need to change them quickly, so a full redeploy is usually too slow.
The same idea works for security incidents. If a newly released feature is being abused, turning it off in seconds can buy time to fix it properly.
Choose what deserves a switch
Not every feature needs one. Good candidates are:
- features that accept untrusted input, such as uploads or imports
- features that call outside services
- expensive operations that can be abused to exhaust resources
- newly released paths with limited production history
Keep the list short. Each kill switch is a state your team has to understand.
Design decisions
- Safe default. Decide what happens when the flag service is unreachable. For a switch that disables a risky feature, the safe default is usually off.
- Degrade, do not crash. The off state should show a clear message or fall back to a simpler behavior.
- Speed. Check how quickly a change reaches every running instance. If caches delay it by minutes, write that number down.
- Who can flip it. Give incident responders a role that can change these flags, and keep the rest of production flag access narrower.
- Record every flip. You will need the timeline for the postmortem.
Test the off state
An untested kill switch is a hope, not a control. Fowler advises testing both states of a toggle being released. For kill switches, schedule a periodic test where you flip the switch in a staging environment and confirm the application behaves as designed.
Avoid using flags to hide a security bug permanently
A switch is a stopgap. If the feature stays off for weeks, fix the issue or remove the feature, and delete the flag. See stale feature flags and expiry dates.
Where Safeguard fits
Safeguard offers autonomous remediation with fix pull requests, off by default with every category on Manual, so a human decides before a fix is proposed or merged. A kill switch buys time, and a reviewed fix replaces it.
Quick check
Should a kill switch be on a separate system from the main flag service?
It can help, because it removes a shared failure point. Whatever you choose, test how the application behaves when the flag source is unreachable.
Sources
Last reviewed: 19 October 2026.
