Feature Flag Hygiene: Remove Stale Flags Before They Cause Outages
Put owners, expiry dates and a monthly cleanup on every feature flag so toggles stay a safety tool instead of becoming hidden risk.
This is for engineering leads and product managers at SaaS companies that adopted feature flags to ship safely and now have dozens nobody fully understands. Old flags make code harder to read, multiply the combinations you never test and occasionally switch off something important by accident. This post shows how to classify flags, assign owners and expiry dates, keep an inventory and run a short monthly cleanup so flags keep doing their job.
An engineer cleaning up configuration turns off a flag called new_checkout_v2, assuming it is leftover from last year. It was, but the old checkout path it guarded had since been deleted, and the flag now controlled whether payments worked for one customer segment. Checkout breaks for those customers for an hour before anyone connects the change to the outage.
Flags are cheap to add and easy to forget. Release toggles, experiments, customer-specific switches and kill switches all live in the same list with similar names. Nobody knows which ones are still needed. Testing covers only the default combination, so the code paths behind rarely used flags quietly rot until someone flips one in production.
A project management SaaS in Pune had accumulated many feature flags over three years, and engineers were nervous about touching any of them. The engineering lead exported every flag, tagged each by type and asked the original creator, or their manager, to claim ownership. Flags fully on everywhere for months were removed along with the dead code. New flags now require a prefix, an owner and an expiry date, and a monthly review clears anything overdue. The codebase became easier to read, onboarding new engineers took less explanation, and the team stopped finding surprise behaviour behind toggles nobody remembered.
How many feature flags is too many?
There is no fixed number. The warning sign is flags nobody can explain or that have been fully on for months. If your inventory has many flags past expiry or without owners, you have more than your team can safely manage.
How long should a release flag stay in the code?
Set your own window, such as a few weeks after full rollout once the feature is stable. After that the flag adds risk without benefit. Remove it along with the old code path.
Should customer-specific features use feature flags?
For a short beta, yes. For permanent differences between plans or customers, model them as entitlements tied to billing and permissions, so they are visible, auditable and not mixed with temporary release toggles.
Do we need a paid feature flag tool?
Not at first. A configuration table with an admin screen and change logging can work. As flag count and team size grow, a dedicated tool helps with targeting, audit logs and inventory. The hygiene rules matter more than the tool.
Want this fixed in your business?
Send the workflow. You get a scope and a fixed price within two working days — or a straight answer that it isn't a fit.