A trading firm experienced a loss of $440 million within 45 minutes. This was not due to a cyber attack or a sudden crash in the market. It was a forgotten and obsolete feature flag that nobody had taken the time to remove. Let's get rid of it once and for all. ## The gun we handed everyone
The 2012 collapse of Knight Capital, one of the major participants in the US stock market, is the cautionary tale that every engineer kind of half-remembers when they're optimizing production error logging. A flag that had been repurposed caused Knight's systems to reactivate the "Power Peg" order router dead code from 2003. One accident of deployment turned it back on. Incorrect trading poured out for 45 minutes, and the company went out of business. Here's the part that bugs me. We learned almost nothing. Feature flags became extremely popular and began to be used in various applications, however, there was no proper method established to effectively manage them. ## The math nobody wants to look at
A report in June 2026 by GrowthBook quantified the chaos. Ten active flags can create 1,024 potential code paths. Twenty flags? Over a million. It is impossible to test a million code paths. You can hardly analyze ten. Therefore, the majority of teams do not analyze them at all, they simply deliver the flag and continue working. And those toggles are never cleaned up. GrowthBook cited a survey indicating that 77% of developers intend to delete toggles once they are no longer needed. Yet 75% of those toggles remain in the codebase for as long as 49 weeks after they are introduced. This proves that intention is not a cleanup strategy. ## Engineers there create 2,300 new flags every month.
DoorDash provided a glimpse in August 2026. The platform oversees over 60,000 feature flags in around 623 repositories. 2300 upcoming flags each month. More than 1000 of those are already marked as stale. If an engineer has to clean up a single stale flag manually, it will take them a full one to two hours of work. Imagine if there are 1,000 stale flags to clean up. Then we have a full-time job that no one wants to do. The issue here isn't specific to DoorDash. It's more about how default behaviors can lead to such situations. Once a flag is put in place, it's hard to get rid of it, so they accumulate over time. And then the stack of wood is ablaze. ## The blast radius is real
In February 2026, LinkedIn experienced a total outage. It was due to an unintentional release that changed all of the feature flags to the on position. Old, untested flags smashed together in combinations never before seen. It's Knight Capital with a better brand. The flag service is actually a single point of failure as well. PostHog's flag service had four different incidents over ten days in October 2025, with more than 14 hours of major impact in total. And that's how a denial-of-service attack can occur through resource exhaustion. Fireship performed a review of all these unaddressed risks and the theme is sadly the same for each one. → Flags are runtime mutations of production behavior
→ We treat them like config, not like deployed code
→ Nobody owns the cleanup, so entropy wins
The discipline gap
Here's what I really think. Feature flags are not the bad guys here. Using them carelessly as if they cost nothing is the real issue. Each flag acts as a runtime switch in your production code. It's a seriously powerful concept. We've made it so common and normalized its usage to such an extent that we removed the necessary guardrails that this level of power should come with. There are some teams that are making an effort. Uber open-sourced Piranha, a tool that hunts down stale flags automatically. Over a six-month period, it created almost 5,000 pull requests to remove dead flags in 10 million lines of code. If that doesn't prove the point, I don't know what will. This is not a nice-to-have. This is you waving the white flag and saying the manual way simply doesn't work past a few hundred flags. The uncomfortable truth is that we should put as much effort and rigor into deleting flags as we do in creating them. Expiry dates, owners, automated audit rules that break the build when a flag smells past its best-by date. None of this is done by default. We simply add the flag, release the feature, and casually walk away. ## What I actually think
I believe we have some redundant flags at my startup. Although, I have a tiny bit of doubt which is why we haven't removed them yet. The doubt you're referring to is the main issue we're all facing in the industry. A flag that you're afraid to remove is like a gun with its safety mechanism deliberately removed. We keep rerunning Knight Capital, crossing fingers that this time our accidental deployment will be a little cheaper. Here's a question for you: How many flags currently exist in your codebase that you could safely delete today, and how many are you just too scared to even think about touching?
Top comments (0)