A 30-Minute Audit for Feature Flags Nobody Remembers

List every flag currently defined in your flagging system, along with when its value or configuration was last changed. A flag whose value hasn't changed in months, especially one fully rolled out to every user or fully rolled back to none, is a strong candidate for removal: the decision it represents has already been made and isn't actively being reconsidered. This first pass usually takes less time than people expect, since most flagging systems can sort and filter by last-modified date directly, without any extra tooling.

Separate out any flag controlling access to a feature, an API surface, or a permission level, since a stale flag in this category isn't just clutter, it's a potential access control gap. A flag meant to gate a beta feature to a specific test account that was never removed after launch can leave that access path open indefinitely, long after anyone remembers it exists. Treat this category with a shorter review cycle than ordinary rollout flags, since the cost of leaving one stale is meaningfully higher.

Security-relevant flags deserve a slightly different review question: not whether the feature is finished, but who could still reach it. For example, a flag that limits a beta API to a test account should be checked against the current access list, and if the beta has launched, the flag and the special access path should be removed together. Give this category a named reviewer and a shorter cycle than ordinary rollout flags. A common mistake is removing the flag but leaving the permission it once granted, so confirm both are gone.

For each flag, check whether there's a name attached, whoever created it or currently owns the feature it gates. A flag with no identifiable owner is one nobody will proactively clean up, because removal always carries some small risk and nobody wants to be the one who breaks something they don't fully understand. Ownerless flags are your highest-priority cleanup candidates precisely because they'll otherwise sit untouched indefinitely, quietly outliving every engineer who could have explained why they were added in the first place.

Flags fully rolled out or rolled back with a clear owner are usually safe to remove immediately: delete the flag and the now-dead code branch it was guarding. For flags that are more complicated to remove, tied to code that's harder to untangle, schedule the work with an owner and a date rather than letting the finding sit in a backlog where it will compete against every other unscheduled task indefinitely.

Sort each flag into one of these outcomes:

• Fully rolled out or rolled back with a clear owner: delete the flag and the dead code branch it guarded, now.
• Tied to code that is hard to untangle: schedule the removal with a named owner and a date.
• Behaving as permanent configuration, such as by customer tier or region: rename or re-tag it as configuration.
• No identifiable owner: treat it as the top cleanup candidate, since nobody will remove it unprompted.

Some flags stop being feature toggles and start functioning as permanent configuration switches, a way to vary behavior by customer tier or region indefinitely, which is a legitimate pattern but a different one from a rollout flag that should eventually be removed. Rename or re-tag these explicitly as configuration rather than leaving them mixed in with genuine rollout flags, so the next audit doesn't waste time re-evaluating a flag that was never meant to be temporary in the first place.

The first audit on a system that's never had one will find the most flags and take the longest; every audit after that gets shorter, because the backlog of neglected flags has already been cleared. Put the next audit on the calendar before you close out this one, with the same owner or a named successor, so the system doesn't drift back to needing a large one-time cleanup again a year from now, once everyone has once again stopped noticing the flags quietly piling up.