Feature Flag Cleanup Matrix

Turn a flag export into stale-flag risk tiers and owner cleanup prompts, all in your browser

The cleanup matrix runs entirely in your browser. Flag keys, owners, environments, and rollout values are not uploaded, logged, or stored. This flags likely-stale flags before a cleanup sprint; it is a review aid, not a guarantee that a flag reported as stale is safe to delete.

Paste a feature-flag export above, then select Generate cleanup matrix to sort flags into stale, review, keep, and active tiers with an owner prompt for each cleanup candidate.

About the feature flag cleanup matrix

The feature flag cleanup matrix turns a pasted feature-flag export into a short, prioritized cleanup list. It reads either a CSV export with a header row or a JSON array of flag objects, maps common column names (flag key, owner, type, environments, rollout, and age or last-modified date), and sorts every flag into one of four tiers. Stale flags are release or general flags that have been fully rolled out or fully off past a stale-age threshold, so they are the safest removal candidates. Review flags need a human decision, such as an old experiment or a flag whose age is unknown. Keep flags are operational, permission, or kill-switch flags treated as permanent. Active flags are still in use and left alone.

Paste your export and select Generate cleanup matrix. A sample export with stale release flags, a permanent ops flag, and missing-owner rows is loaded so you can see the tiers right away. Everything runs in your browser. The flag keys, owner handles, environments, and rollout values are never uploaded or stored, and analytics records only coarse count bands. Each cleanup candidate comes with an owner prompt you can send. Download a cleanup CSV for the full report or copy a markdown cleanup plan to paste into a cleanup-sprint ticket or a release-governance review.

How to use

  1. Paste your feature-flag export into the box. A sample CSV is loaded so you can see how it works; a JSON array of flag objects works too.
  2. Make sure the export has a flag-key column (flag_key, flag, key, or name). Owner, type, environments, rollout, and age or last-modified columns are used when present.
  3. Select Generate cleanup matrix to sort every flag into stale, review, keep, and active tiers using the default stale-age thresholds.
  4. Read the summary and the matrix. Stale flags are listed first, each with an owner prompt for the next step. Missing-owner flags are flagged.
  5. Select Download cleanup CSV for the full report, or Copy cleanup plan to paste a markdown summary of the removal candidates into a ticket or review.

Worked examples

A fully rolled-out release flag is flagged stale

A release flag at 100 percent rollout that was last changed 142 days ago is past the 30-day release threshold, so it is reported stale with a prompt to confirm removal with its owner.

A permanent kill-switch is kept, not flagged for removal

An ops or permission flag, such as an emergency kill-switch, is treated as permanent infrastructure. It stays in the Keep tier no matter how old it is, though a missing owner is still surfaced.

An old experiment is routed to review, not auto-removed

An experiment flag older than 60 days is sent to the Review tier with a prompt to confirm the experiment has concluded, rather than being marked safe to delete automatically.

Frequently asked questions

What does the feature flag cleanup matrix do?
It turns a pasted feature-flag export into a prioritized cleanup list. It maps your columns to flag key, owner, type, environments, rollout, and age, then sorts each flag into a stale, review, keep, or active tier. Stale flags are the safest removal candidates (fully rolled out or off past a threshold), review flags need a human decision, keep flags are permanent operational or permission flags, and active flags are still in use. Each cleanup candidate gets an owner prompt for the next step.
How does it decide a flag is stale?
It uses default per-type stale-age thresholds: a release flag is stale once it has been fully on or fully off for at least 30 days; an experiment flag is sent to review after 60 days; any other fully on or off flag is stale after 45 days. Operational, permission, and kill-switch flags are treated as permanent and are never marked stale by age. Partially rolled-out flags stay active. Thresholds are conservative defaults for first ship; configurable thresholds are a planned follow-up.
What export formats does it read?
It reads a CSV export with a header row, or JSON. For JSON it accepts an array of flag objects, an object that wraps a flags or featureFlags array, or an object map keyed by flag name. It maps common column and field names case-insensitively, so flag_key, flagKey, and name all map to the flag key, and rollout, rollout_percentage, and state all map to rollout. Vendor-specific export dialects are a planned follow-up; for now, a generic CSV or JSON export works best.
Is my flag export uploaded anywhere?
No. Parsing, classification, prompt generation, and export all run in your browser. The flag keys, owner handles, environments, and rollout values are never sent to a server or saved. Analytics records only coarse count bands, never the flag data. Feature-flag exports can reveal unreleased features, rollout strategy, and owner names, so download the cleanup CSV or copy the plan before you close the tab.
Is a stale flag safe to delete?
Treat the matrix as a review aid, not a guarantee. A flag reported as stale is a strong removal candidate, but you should still confirm with the owner that the code path is no longer needed before deleting it. The owner prompt for each candidate is written to make that confirmation easy. Keep and review tiers exist precisely because some flags should not be removed on age alone.

Use this again tomorrow

Save this page so it's one tap away when you need a quick result.

Bookmark this tool

Ready for a quick Daily Challenge?

Play Daily Challenge on sts.games