Kill switches: the feature flag you hope you never use
A kill switch is a feature flag that turns off a risky part of your system in seconds. Where to put them, how to design them, and how to make sure they work.
A kill switch is a feature flag whose job is to turn something off, fast, during an incident. It is an ops flag, and unlike release flags it is often meant to stay in the code permanently.
When a third-party API starts timing out, a new recommendation engine overloads the database, or a promotion is sending the wrong emails, the fastest fix is not a revert and a deploy. It is a switch someone can flip in seconds.
Where kill switches pay off
- Calls to external services: payments, email, search, AI models. If the provider is down, skip the call and fall back.
- Expensive features: recommendations, live counters, heavy reports. Turn them off to save the core of the product under load.
- Background jobs and batch sends: stop a job that is doing the wrong thing before it finishes.
- Newly launched features: keep the release flag around as a kill switch for the first weeks.
- Integrations that write data: stop syncing to a partner system while you investigate.
Design rules
Off must be safe. Decide what the product does when the switch is off, and build that fallback first: a cached result, a simpler version, a friendly message. A kill switch that throws errors when off just moves the outage.
Fail toward the safe value. If the flag service cannot be reached, the SDK returns the default value from your code. For a kill switch, choose that default deliberately. Usually it means the feature stays on (normal behavior), but for something dangerous it may mean off.
Name it for what it does. payments-provider-enabled or disable-recommendations is clear at 3 a.m. flag-2291 is not. Pick one convention (enabled/disabled) and keep to it, because a double negative during an incident leads to the wrong click.
Make it fast. Check how long a change takes to reach every server. Streaming updates apply within seconds; polling every five minutes may be too slow for an incident.
Control who can flip it. Your on-call engineers need access without waiting for an approval flow, and every change must be in the audit log.
Test it before you need it
A kill switch that has never been flipped is a guess. Flip it in staging as part of your release process, and in production during a planned game day:
- Turn it off and check the fallback works and errors stay flat.
- Measure how long the change took to reach every instance.
- Turn it back on and check the system recovers cleanly.
Write the switch into the runbook for the alerts it is meant to fix, so the person on call knows it exists.
Summary
Kill switches are cheap to add and very valuable on a bad day. Put them in front of external calls and expensive features, make "off" a safe, tested state, and keep them where the on-call team can find them.