How to Clean Up Stale Feature Flags in LaunchDarkly
Feature flags are cheap to create and expensive to keep. Every flag left in the code after launch adds a branch nobody tests, a decision someone has to understand, and a small risk that a mistaken toggle changes production behavior. Teams that use flags heavily can end up with hundreds of them, most of which serve the same value to everyone.
LaunchDarkly provides tools to find flags that are ready to remove, including flag statuses and code references. This guide covers how to identify stale flags, confirm they are safe to remove, clean up the code, archive the flag, and build habits that keep flag debt from piling up again.
Rolling out behind a flag? Write the experiment brief before you ship.
Describe the change and the number you want to move. Vantage turns it into a written brief you can share with eng and data before anything ships.
How this works
- We save what you typed. No AI runs on this page.
- You create a free account.
- Vantage builds an experiment brief from it inside your own workspace.
Why ask for an account? We’re a small team, and a full generation runs a multi-step AI pipeline that costs us real money. So we tie it to a free account instead of running it anonymously. You also get to keep the result and edit it.
Your text is only used to create your project, and it stays private to your account. If you don’t sign up, we delete it after 7 days. Privacy policy
Step-by-step guide
Separate temporary and permanent flags
Not every flag should be removed. Kill switches, entitlement flags, and operational toggles may be permanent by design. LaunchDarkly lets you mark flags as temporary or permanent. Mark them accurately so cleanup work focuses on temporary release flags.
- Review flags and mark each as temporary or permanent
- Use tags to group flags by team or feature area
- Assign a maintainer to every flag
Use flag statuses to find candidates
LaunchDarkly shows a status for flags based on their evaluation activity, such as whether a flag is active, inactive, or launched (serving one variation to everyone). A temporary flag that is launched or inactive is a strong cleanup candidate. Filter the flag list by status to build a candidate list.
Check code references
LaunchDarkly's code references feature scans your repositories and shows where each flag key appears in code. Set it up in your CI so references stay current. Before removing a flag, check every location it is referenced, including tests and other services.
- Set up code references for your repositories
- Open the flag and review where it appears in code
- Check for references in multiple repositories or services
- Note any places where the flag value drives configuration rather than a simple branch
Remove the flag from code
Create a ticket for each flag removal or batch them by feature area. In the code, keep the branch that is currently served and delete the other path, along with tests for the removed path. Deploy the change and confirm the flag is no longer being evaluated.
- Keep the code path for the variation currently served
- Delete the old path and related tests
- Deploy to all environments
- Confirm in LaunchDarkly that evaluations have stopped
Archive the flag in LaunchDarkly
Once the code no longer references the flag and evaluations have stopped, archive the flag. Archiving removes it from the active list while keeping its history. Avoid archiving flags that are still evaluated, because the SDK will fall back to the default value in code.
Set a cleanup cadence
Make flag cleanup a recurring task rather than an occasional project. A monthly review of launched temporary flags, with removal tickets added to the next sprint, keeps the number manageable. Track the count of active temporary flags as a simple health metric.
Plan cleanup when the flag is created
The easiest way to avoid stale flags is to create the removal ticket at the same time as the flag. Add an expected removal date to the flag's description and link the ticket. When the feature reaches full rollout, the cleanup work is already planned.
Common mistakes
Archiving before removing code
If code still evaluates an archived flag, it will receive the fallback value, which may not match what users were seeing. Remove code references first.
Treating permanent flags as debt
Kill switches and entitlement flags are meant to stay. Marking them correctly prevents someone from removing a safety mechanism.
No owner for old flags
Flags created by people who have left the team often linger because nobody feels responsible. Reassign maintainers when people change roles.
Tips
Use a tag per quarter or per launch to batch cleanup work.
Add flag cleanup to your definition of done for features released behind flags.
Report the number of launched temporary flags in engineering health reviews.
Keep flag names descriptive so their purpose is clear without opening the code.
How Vantage helps
Flag debt usually starts as a missing ticket. When Vantage generates tickets from a PRD, cleanup and rollout work can be generated alongside the feature work, with dependencies mapped, so removing the flag is part of the plan that lands in Linear or Jira rather than a task someone remembers later.