Kill switch
Feature flag kill switch: recover in seconds
A kill switch is a feature flag whose job is the worst five minutes of your week: one click turns a misbehaving feature off for every user, in about 3 seconds, without touching the deploy.
01 · The same incident, twice
45 minutes of rollback, or 3 seconds of flip
The bug is identical in both timelines. The only difference is whether recovery means rebuilding and redeploying the past, or flipping a switch that was waiting for exactly this.
Without a kill switch
~45 minAlerts fire: checkout errors climbing.
Diagnosis: this morning's release. Decision: revert.
Revert PR opened, approved, merged.
CI builds. Everyone watches a progress bar.
Deploy rolls across instances, pods cycle.
Error rate back to baseline. 45 minutes of angry carts.
With a kill switch
~3 sAlerts fire: checkout errors climbing.
Diagnosis: this morning's release, behind checkout.new-flow.
Kill switch clicked in the Toggled console.
SDKs converge; every user is back on the old flow.
Error rate at baseline. Fix ships on your schedule, not the pager's.
Timings illustrative: SDK convergence is typically ~3 seconds
02 · Under the hood
Why the flip takes seconds, not minutes
Toggled SDKs hold a streamed copy of your ruleset in memory. When you hit the kill switch, the change streams to every connected SDK and the next evaluation returns the old path. Nothing rebuilds, nothing redeploys, no pods cycle: the buggy code is still deployed, it just stops being executed.
And because the switch works during our bad day too, SDKs fail safe: if Toggled is unreachable, they serve the last-known ruleset and your coded defaults. An outage on our side never blocks a recovery on yours.
Four rules for a kill switch you can trust
- 01 Keep the old path alive. A kill switch with nowhere to land is decoration. The old code stays deployed and tested until the new path has earned 100% for good.
- 02 Test the OFF flip. Flip it in staging on purpose, regularly. The switch you have never flipped is the switch that fails at 2am.
- 03 No flag chains. The kill path must not depend on three other flags being in the right state. One switch, one decision, one outcome.
- 04 Give it an owner. On-call knows exactly which switch maps to which surface, from the incident runbook, before the incident.
03 · Part of the lifecycle
Every flag you ship is already a kill switch
You do not build kill switches as a separate project. Ship features behind flags and the recovery button comes free: the same toggle that ran your canary deployment and your gradual rollout is the switch that ends the incident. The long-lived ops variety gets its own discipline, covered in feature toggle management.
A bad release
The classic: new checkout misbehaves, flip it off, everyone lands on the flow that worked yesterday.
A struggling dependency
Payment provider degrading? Kill the integration flag and route around it while they recover.
Load shedding
Traffic spike: turn off the expensive recommendations panel and keep the core product fast for everyone.
Want the practice run? The live console on the homepage has a kill switch wired to 100 simulated users. Read the incident-day playbook in kill switches: recover in seconds, not a redeploy.
Early access · launching soon
Be 3 seconds from safe, not 45 minutes
Toggled is in early access. Join the list and ship your next release with an exit. Flat pricing, unlimited seats, no card required.
No card required · your data stays yours
Keep exploring
More feature flag resources
- React Feature Flags
- Next.js Feature Flags
- Node.js Feature Flags for APIs and Backends
- Python Feature Flags for Django, Flask and FastAPI
- Go Feature Flags With Sub-Millisecond Checks
- Feature Flags Platform
- Managing Feature Flags
- Feature Flag Tools
- A/B Testing Software Powered by Feature Flags
- Feature Flag Service Use Cases for Product Teams
- Feature Flag Software Pricing, Unlimited Seats
- Feature Flags Explained