Stale flag

Most flags are meant to be temporary, and they go stale in predictable ways: a percentage rollout reaches 100% and nobody deletes the flag; an experiment ends and the losing variation lingers as dead code; a feature is rolled back and abandoned; or a flag is created and never wired into the application. The exception is intentionally permanent flags — a kill switch serves one variation for months by design, which is why staleness should prompt a review rather than an automatic delete.

Featureflip classifies every flag in every environment as Active, Stale (a staleness signal has persisted for 30 days), or Dead (90 days) by analyzing real evaluation traffic — no codebase scan or configuration required. Each status carries the reasons: fully rolled out, rolled back, no traffic, or never used. See the stale flag detection guide for the full model and cleanup workflow. Detection models differ across vendors: time-based reports such as ConfigCat's zombie flags report key off when a flag was last changed, which misses flags that are still touched but serve one variation to everyone; Flagsmith's flag analytics likewise report raw evaluation counts and leave the finished-flag call to you. The guide to ConfigCat alternatives and the Flagsmith alternatives guide compare staleness tooling across platforms.