Stale Flag Detection
Featureflip automatically classifies every flag in every environment as Active, Stale, or Dead based on the evaluation traffic it actually receives. There is nothing to install or configure: detection runs continuously, and flags that have stopped making real decisions surface in the dashboard with the reasons attached.
Why stale flags matter
Section titled “Why stale flags matter”Most feature flags are meant to be temporary. A rollout flag should be deleted once the feature is at 100%; an experiment flag should be deleted once the experiment has a winner. In practice, deletion gets deferred, and every leftover flag is a conditional branch your team still has to read, test, and debug around.
The hard part of cleanup has always been the first step: knowing which flags are actually done. Staleness detection answers that question for you, from evaluation data rather than guesswork.
The three statuses
Section titled “The three statuses”| Status | Meaning |
|---|---|
| Active | The flag is making real decisions: traffic is flowing and more than one variation is in play (or it is too early to tell). |
| Stale | A staleness signal has persisted for the last 30 days. The flag is probably finished, and the team likely still has context to remove it cheaply. |
| Dead | The same signal has persisted for the last 90 days. The flag has not made a meaningful decision in three months and is a clear removal candidate. |
Statuses are recomputed hourly from evaluation analytics, so a flag that becomes active again — for example, you re-enable it or change its targeting — moves back to Active on the next pass without any manual reset.
What detection looks for
Section titled “What detection looks for”Each flag-environment is checked for four independent signals. A flag can carry more than one.
| Signal | Fires when | What it usually means |
|---|---|---|
| Fully rolled out | The flag is enabled, serving a fixed single variation, and at least 99.9% of evaluations return that variation. | The rollout is complete. Ship the winning code path unconditionally and remove the flag. |
| Rolled back | The flag is disabled and at most one variation has been served in the window. | The feature was turned off and abandoned. Decide whether it is coming back; if not, remove it. |
| No traffic | The flag is enabled but received zero evaluations in the window, despite having traffic before. | The code path that evaluates the flag no longer runs — often the reference was already deleted. |
| Never used | The flag was created 30+ days ago (90+ for Dead) and has never been evaluated in this environment. | The flag was created speculatively or for an environment it is not wired into. |
Per-environment detail and roll-up
Section titled “Per-environment detail and roll-up”Detection runs per environment, because flags are usually finished in some environments before others — fully rolled out in production while a forgotten staging config still serves both variations, for example.
- The flag list shows one badge per flag: the worst status across all of its environments, with the combined reasons.
- The flag detail Environments tab shows each environment’s own status and reasons, so you can see exactly where a flag is still live before removing it.
- The flag list can be filtered by staleness status to produce a ready-made cleanup queue.
What staleness detection is not
Section titled “What staleness detection is not”It does not scan your codebase. Featureflip sees how flags behave in running systems, not where they are referenced in your repository. Before deleting a flag, find its references with a code search and remove them first — the feature flag cleanup guide covers a practical workflow, including the two-PR removal pattern.
It does not act on flags for you. Detection is a signal, not an enforcement mechanism. Featureflip never archives, disables, or deletes a flag on its own; the statuses exist to make your cleanup decisions cheap and well-informed.
Permanent flags will show up — by design. A kill switch that has served true to everyone for a year is, by traffic analysis, indistinguishable from a finished rollout. Treat the badge as a review prompt rather than an order: if a flag is intentionally permanent, that is a fine answer, and the badge simply tells you it is worth confirming the intent still holds.
Next steps
Section titled “Next steps”- What Are Feature Flags? — flag types, variations, and the flag lifecycle
- Environments — manage separate configurations for dev, staging, and production
- Feature flag cleanup — the detect, triage, remove, prevent loop, with code-search tooling
- Rollout Strategies — percentage rollouts and fixed serving
Frequently Asked Questions
Section titled “Frequently Asked Questions”What is a stale feature flag?
Section titled “What is a stale feature flag?”A stale feature flag is a flag that no longer makes a live decision in your application: it serves the same variation to everyone, receives no evaluation traffic, or was created and never used. Stale flags accumulate as technical debt, because every one is a conditional branch engineers still have to read, test, and reason about. Featureflip detects them automatically by analyzing real evaluation traffic in each environment and assigning each flag a status of Active, Stale (signal persisted for 30 days), or Dead (signal persisted for 90 days), with the specific reasons attached.
How does Featureflip detect stale and dead flags?
Section titled “How does Featureflip detect stale and dead flags?”Featureflip analyzes the evaluation traffic each flag actually receives in each environment. No agents, build steps, or configuration are required. Every hour, each flag-environment is checked for four signals: fully rolled out (enabled and serving one variation to at least 99.9% of evaluations), rolled back (disabled with at most one variation served), no traffic (enabled but receiving zero evaluations), and never used (created but never evaluated). A signal that persists across a 30-day window marks the flag Stale; across a 90-day window it marks the flag Dead. The flag list shows a badge with the worst status across environments, and the flag detail view breaks the status down per environment.
What is the difference between a stale flag and a dead flag?
Section titled “What is the difference between a stale flag and a dead flag?”The difference is how long the flag has shown no real decision-making activity. Stale means a staleness signal, such as serving a single variation to effectively all users or receiving no traffic, has persisted for 30 days. Dead means the same signal has persisted for 90 days. Stale is the early warning: the flag is probably finished but recent enough that the team still has context. Dead is the strong signal: the flag has not made a meaningful decision in three months and is a clear candidate for removal from code and then from the platform.
Does Featureflip scan my codebase for flag references?
Section titled “Does Featureflip scan my codebase for flag references?”No. Featureflip analyzes evaluation traffic, not source code, so it knows how flags behave in running systems but not where they are referenced in your repository. The two approaches are complementary: traffic analysis tells you which flags have stopped making decisions in production, and a code search tells you where each flag lives so you can remove it. Before deleting a flag, find and remove its references with a code search, then delete the flag from Featureflip. Removing the code first prevents the SDK from silently serving fallback values.