Stale feature flags leave conditionals and untested code paths in your application. Control them by creating a removal task when you add a flag, giving each one an expiry date, and capping the number of active flags. These are practices described in Martin Fowler's feature toggle article.
What a stale flag costs
Fowler is direct that toggles carry a cost: they add abstractions, conditionals and testing burden. A flag that has been on for everyone for six months is pure cost. The old branch is dead code, and the new branch is just code, wrapped in an if statement.
From a security view the cost is sharper. A forgotten flag that guards an old code path might guard a path with a known weakness. If the flag flips back, even by accident, the weakness is live again.
Three practices from the source
- Add a removal task to the backlog when you introduce a release flag. The cleanup is planned on day one, when you remember why the flag exists.
- Use expiration dates or time bombs. A time bomb is a test that fails or a startup check that blocks after the flag has passed its date. It turns a forgotten item into a visible failure.
- Cap the number of active flags. Adding one means removing another.
How to find stale flags today
- Export the list of flags and sort by last modified date.
- Mark any flag that is 100 percent on or 100 percent off for everyone.
- Search the code for each flag key to see where it is used.
- Check whether any flag has no owner.
You do not need a tool for this on day one. A spreadsheet with flag, type, owner, created date, expiry date and status is enough to start.
Removing a flag safely
- Confirm the flag is fully on or fully off in every environment.
- Remove the losing branch and the flag check in one change.
- Run the tests for the surviving behavior.
- Delete the flag from the flag service after the change is released, so a rollback still works until then.
Fowler also notes that you should test both states of a flag being released, but not every combination of flags. That keeps the test matrix manageable while flags are alive.
Where Safeguard fits
Dead code also hides in dependencies. Safeguard reachability analysis shows which vulnerable code your application actually calls, which helps you prioritize real exposure over unused paths.
Quick check
Should we delete the flag first or the code first?
Remove the code and the flag check together in one release, then delete the flag record afterwards so a rollback stays possible.
Sources
Last reviewed: 19 October 2026.
