AI-native
Kill switch or rollback: which should you use when a release breaks?
Use the kill switch first when the broken thing is behind a feature flag: it turns off one feature in seconds and leaves everything else alone. Roll back the deploy when the problem isn't behind a flag, or sits outside any flag, such as a schema change or a process that won't start.
Updated November 14, 2026
How do they differ?
Flagger.gg's guide to kill switches compares them:
| Kill switch | Rolling back a deploy | |
|---|---|---|
| What it turns off | One feature; everything else stays | Every change in the release |
| How long it takes | Seconds: apps pick up the change within a second | A build and a deploy |
| Needs the code to be flagged | Yes | No |
| Fixes a bad migration or a crash at start | No | Sometimes |
| Undo | Revert the flag | Deploy again |
Why is a kill switch so fast?
Because nothing is rebuilt. Flagger.gg's SDKs hold the rules in memory and follow a stream; after a change the service pushes the new rules within a second, and if the stream is down the SDK polls every five seconds. There's no build, no deploy and no cache to purge. A kill also never needs approval, is exempt from per-agent rate limits, works on protected flags, and writes an audit entry with who did it, which run and why.
flagger kill checkout_v2 --note "500s on /checkout" --json
flagger revert checkout_v2 --note "fix deployed" --jsonWhen is a rollback the only option?
When the bad change isn't behind a flag, or can't be. A migration that broke the schema, a dependency upgrade that crashes the process at start, or a config change the flag never touches all need the release itself undone. That's why every deploy should keep a one-step rollback, as North Bay Ventures' do; see how we build companies.
What should live behind a permanent kill switch?
Every new feature gets a release flag that doubles as its kill switch until the flag is removed. Some switches are worth keeping for good:
- calls to third parties, such as a payment, email or AI provider, so you can stop calling one while it's down;
- expensive work, such as a heavy report or a background job, so you can shed load;
- risky write paths, such as a new sync or import, so you can stop them before they touch more data.
Write each check so that off is the safe answer. Flagger.gg's SDKs treat an unknown, not-loaded or errored flag as off.
What about changes an AI agent shipped?
Give each agent change its own flag and tag it with the agent's run, and you can turn off one change, or everything one run shipped, without touching the rest. Then cut the agent's access if you need to. The full order is in how to stop an AI agent that's going wrong; for the bigger picture, see feature flags vs feature branches.
Frequently asked questions
Is a kill switch the same as a feature flag?
A kill switch is a feature flag used to turn something off fast. Every release flag works as one until it's removed; some are kept permanently.
How fast does a Flagger.gg kill take effect?
Within a second for connected apps, because the SDKs evaluate flags in memory and receive changes over a stream.
Can an AI agent use the kill switch?
Yes, if its token has the kill action. A kill works even on protected flags and never needs approval.
Should I still keep deploy rollbacks?
Yes. A kill switch only covers code behind a flag. Schema changes, crashes at start and unflagged code need a rollback.