How do I know when a flag is stale and ready to be removed?

A flag is usually stale when it no longer has a clear, active purpose and is mostly just “living in the code.” Good signs it’s ready to be removed:

Clear signs a flag is stale

• It’s always on or always off in production.
• Its original rollout has completed and no rollback path is needed.
• No one can explain why it still exists.
• It hasn’t been changed or referenced in a long time.
• Telemetry shows it no longer varies by user, cohort, region, or environment.
• The code path behind it is now the default and the flag only gates dead or duplicate logic.
• The owning team has stopped tracking it or it’s missing from your flag inventory.
• It’s past its intended expiration date.

Practical checklist

Ask:

1. What problem does this flag still solve?
2. Is it still used for rollout, experiment, kill switch, tenant config, or compliance?
3. What would break if I removed it?
4. Is there any runtime dependency on it from another system?
5. Can we verify from logs/analytics that the flag value no longer matters?

If you can’t answer #1 or #3 with something concrete, it’s probably stale.

Safe removal process

• Confirm the flag is inactive in all environments you care about.
• Check metrics, logs, and any dashboards for recent variation.
• Remove the flag in a small change, not a giant cleanup.
• Delete dead branches, tests, docs, and config entries tied to it.
• Watch for regressions after deployment.

Good rule of thumb

If a flag has been unchanged, unobserved, and unnecessary for multiple release cycles, it should be reviewed for removal.

If you want, I can also give you a stale-flag checklist for code reviews or a policy for automatically expiring flags.