A kill switch is a feature flag designed specifically for instant emergency deactivation of a feature. Unlike release flags that get cleaned up after a rollout completes, a kill switch stays in the codebase permanently. Its job is to provide a way to turn off a feature in seconds, at any time, even years after the feature shipped.
The scenario is familiar to any team that has operated software at scale: a feature that worked fine for six months suddenly causes problems. Maybe a backend dependency degrades. Maybe a new edge case surfaces at higher traffic. Maybe a partner API changes behavior. Without a kill switch, fixing the problem requires a code change, a build, a deploy, and a review. With a kill switch, one person flips a flag and the feature is off while the team investigates.
When should you use a kill switch?
Kill switches make sense for features that interact with external dependencies, handle critical user flows, or have failure modes that can't be fully predicted at ship time.
External integrations. Any feature that depends on a third-party API, a partner service, or a data feed outside your control should have a kill switch. When that dependency goes down, your feature goes down with it. A kill switch lets you degrade gracefully instead of failing visibly.
Payment and checkout flows. Features in the critical purchase path carry outsized risk. A bug that prevents users from completing a purchase has immediate revenue impact. A kill switch that reverts to the previous checkout experience is worth the small cost of maintaining the flag.
New infrastructure. When a team migrates to a new backend, database, or service architecture, a kill switch on the new path provides a fast fallback to the old one. This is standard practice during service migrations at Spotify, where the blast radius of an infrastructure problem can span hundreds of millions of users.
For simpler features with well-understood failure modes, a kill switch may be unnecessary. The decision comes down to the cost of maintaining the flag versus the cost of not being able to turn the feature off quickly.
How is a kill switch different from a regular feature flag?
The mechanism is identical. A kill switch is a feature flag. The difference is in intent, lifecycle, and coding convention.
A release flag is temporary. It controls a rollout, and the team removes it after the feature reaches 100% and stabilizes. A kill switch is permanent. It stays in the code because its value comes from being available at any time in the future.
Because kill switches are permanent, they need to be coded differently than temporary flags. The default state should be "feature on." The kill switch only activates to turn the feature off. This means a Confidence outage or a flag configuration error defaults to the feature being active, which is the expected behavior for a shipped feature. You only want the kill switch to fire when someone explicitly triggers it.
In Confidence, a kill switch is implemented as a feature flag with a boolean property. The flag evaluates in-process at 10 to 50 microseconds, adding negligible latency. Since evaluation doesn't require a network call, the kill switch works even if the Confidence backend is unreachable.
How do you manage kill switch debt?
Kill switches don't accumulate the same kind of technical debt as forgotten release flags, because they're meant to persist. But they still need maintenance.
Document the purpose. Every kill switch should have a description explaining what it deactivates and why. A flag named disable_partner_recommendations with no documentation becomes a mystery in two years when the original team has rotated.
Test both states. If a kill switch exists, both the "on" and "off" code paths need to work. The "off" path is easy to neglect because it never runs in production. Include both paths in integration tests. A kill switch you can't actually flip in an emergency provides false confidence.
Review periodically. Some kill switches outlive their purpose. If the feature they protect has been rewritten, or the external dependency has been replaced, the kill switch is dead code. A quarterly review of active kill switches catches these cases.