Every team that adopts feature flags does it for the same reason: to decouple deploy from release, and to have a fast, low-risk way to turn something off when it goes sideways. That's a good instinct. It's also how you end up with three thousand flags in production, half of which nobody remembers the purpose of, and a codebase where "just flip it off" requires archaeology before it requires courage.
I've watched this pattern play out enough times to recognize the shape of it. A team introduces flags as a safety valve. The safety valve works so well that it becomes the default way to ship anything remotely risky. Within a year, flags aren't a targeted mitigation tool anymore — they're a second, invisible configuration layer sitting on top of the actual code, and nobody has a clean mental model of which combinations of flag states have ever actually been tested together.
The Kill Switch You Can't Find Isn't a Kill Switch
The whole value proposition of a feature flag as an incident tool is speed: something breaks, you flip a switch, the blast radius shrinks immediately, no deploy required. That only holds if the person on call at 3am can find the right flag, understands what it controls, and trusts that flipping it won't cause a second incident on top of the first.
In practice, flag sprawl erodes all three of those conditions. The flag naming convention drifted two reorgs ago. Half the flags that "control" a behavior are actually just one of several layers gating it, and turning off the wrong one does nothing while giving everyone false confidence that mitigation happened. And nobody has validated in months whether the "off" state of a given flag is even a code path that still compiles cleanly, because nobody exercises it — the flag has been at 100% for so long that the off branch is effectively unmaintained legacy code hiding inside a conditional.
That last part is the trap. A flag that's been fully rolled out for a year isn't a safety mechanism anymore. It's dead code wearing a safety mechanism's costume. The moment you actually need it during an incident is the worst possible moment to discover that the fallback path has silently rotted.
Flags Need the Same Discipline as Any Other Production Dependency
The organizations that get this right treat flags as a lifecycle, not a one-way ratchet. A flag gets created for a specific purpose, it gets exercised in both states periodically so the off-path doesn't rot, and — critically — it gets deleted once its job is done. Not "deprioritized for cleanup." Deleted. The backlog ticket to remove a fully-rolled-out flag should have the same urgency as a security patch, because an unmaintained flag is exactly the kind of latent risk that turns a routine incident into a confusing one.
This is also why flag ownership matters more than teams initially think. A flag with no clear owner is a flag nobody will confidently touch during an incident, because touching it means guessing at blast radius rather than knowing it. If your incident responders have to Slack around asking "does anyone know what this flag does" while the system is on fire, the flag has already failed at its one job.
There's a related discipline worth naming: testing flag combinations, not just individual flags in isolation. The incidents I've seen caused by flags weren't usually caused by a single flag misbehaving — they were caused by two flags interacting in a state nobody had tried before, because each was tested independently and shipped independently, and the cross product of their states was never validated anywhere.
Treat Flags Like Infrastructure, Not Like Free Configuration
The uncomfortable truth is that feature flags feel cheap to add and expensive to remove, which is exactly backwards from how they should be treated if you want them to be reliable incident tools. Cheap-to-add, hard-to-remove is the recipe for the kind of accumulated risk that doesn't show up on any dashboard until the night it matters.
If your team leans on flags as a recovery mechanism, the actual test isn't whether you have them — it's whether someone, recently, has actually flipped one under realistic conditions and confirmed the fallback path still works. If the honest answer is "not in months," that flag isn't a kill switch. It's a rumor of one, and rumors don't help you at 3am.