Feature Flag Cleanup Checker

Feature flag inventory:

Header aliases cover common catalog exports. Headerless rows use the legacy order shown in the help tooltip.

Review label:

Use a label that will still make sense in a cleanup ticket or release review.

Cleanup policy:

The three values are stale age, recent-usage window, and expiry grace. Use Advanced only when local policy differs.

Reference date:

Use today for a live review or a release date for a planned cleanup sweep.

Stale-age override:

Use 0 for the policy default; otherwise choose 14–730 days.

days

Usage-window override:

Use 0 for the policy default; otherwise choose 7–180 days.

days

Permanent-control review:

Off is neutral and leaves permanent controls out of the cleanup queue.

{{ params.include_permanent_review ? 'Include review lane' : 'Leave unchanged' }}

Owner-gap escalation:

Off is neutral; owner gaps remain visible evidence without changing the action lane.

{{ params.escalate_owner_gaps ? 'Escalate to review' : 'Evidence only' }}

Cleanup plan

{{ planHeading }}

{{ action }}

The hygiene score and priority points are repository-authored triage signals. They do not verify environment coverage, SDK fallbacks, or safe deletion.

Flag	Owner	Lifecycle	Age	Rollout	Usage	Decision	Evidence	Copy
{{ row.key }}	{{ row.owner }}	{{ row.lifecycle }}	{{ row.age_label }}	{{ row.rollout_label }}	{{ row.usage_label }}	{{ row.decision }}	{{ row.evidence }}

Priority	Flag	Owner	Lane	Next action	Evidence	Copy
{{ row.priority }}	{{ row.key }}	{{ row.owner }}	{{ row.decision }}	{{ row.next_action }}	{{ row.evidence }}

A feature flag lets application behavior change without a new code deployment. That flexibility supports gradual rollouts, experiments, emergency kill switches, permissions, and operational controls. Temporary flags become maintenance debt when their final state is known but branches, platform entries, dashboards, tests, and ownership records remain.

Safe cleanup needs more than age. A flag at 100% may still have live code references, while a flag with no recent evaluations may depend on a seasonal workflow. An expired flag can be blocked by another flag, and a permanent control should not be treated like an abandoned release toggle.

Lifecycle evidence includes creation and expiry dates, current status, flag type, and rollout percentage.
Usage evidence includes recent evaluation counts and the last-seen date.
Removal evidence includes code-reference counts, dependencies, environments, and the fallback behavior that remains after deletion.
Accountability evidence includes an owner and notes that explain why a permanent control still exists.

Cleanup should be sequenced rather than treated as one delete action. Resolve dependencies and unfinished rollouts first. Remove code branches and confirm the remaining default behavior next. Archive the flag in its management system only after every affected environment and client path has been checked.

Age and usage windows are local policy choices, not universal standards. A strict launch gate may treat a 30-day-old flag as stale, while a quarterly review waits 90 days. The reference date also matters because the same inventory can move between Current, Review, Remove code, and Archive candidate as time passes.

A cleanup score is useful for sorting work, but it cannot prove deletion safety. Runtime evaluations, stale clients, offline configurations, SDK defaults, and unreported code references can all sit outside a catalog export.

How to Use This Tool:

Use one inventory capture and one explicit date so every flag is judged against the same cleanup policy.

Paste the Feature flag inventory or load one CSV or TXT file. A header row is preferred; common aliases for owner, lifecycle, rollout, usage, code-reference, dependency, environment, and notes fields are recognized.
Choose a Cleanup policy and Reference date. Use today for a live review or a planned release date for a future sweep.
Override stale age or usage window only when local policy differs. Zero keeps the selected profile. Enable Permanent-control review or Owner-gap escalation only when those rows should enter the review queue.
Start with dependency and rollout blockers, then open code-removal work before archive work. Use the ledger to check the exact evidence and next action for each flag.
Verify code searches, dependency graphs, SDK fallback values, environment coverage, and recent production evaluations before removing or archiving a flag.

Interpreting Results:

The cleanup queue contains Blocked, Remove code, Archive candidate, and Review decisions. Monitor rollout, Current, and Archived rows stay in the ledger but do not enter that queue. Clear stronger decisions before weaker ones because dependency or rollout evidence can make a superficially stale flag unsafe to remove.

Dependency block means cleanup evidence exists but one or more flag dependencies remain.
Resolve rollout state means an expired flag is still partly rolled out.
Remove code means cleanup evidence exists and code references are present or unknown.
Archive candidate means code references are explicitly zero and the lifecycle or usage evidence supports retirement.
Owner review, Add cleanup date, and Permanent review close governance gaps rather than authorize deletion.

The hygiene index decreases as queued priority points increase. Use it to compare inventories produced under the same policy and reference date, not as a universal maturity score or a release gate.

Technical Details:

Each CSV row is normalized into lifecycle, rollout, date, count, ownership, dependency, environment, and note fields. Header aliases are recognized when at least two known column names appear; otherwise the parser uses the fixed legacy column order. The inventory is limited to 200 flag rows and 200,000 characters.

Policy windows

Feature flag cleanup policy windows
Policy	Stale age	Usage window	Expiry grace
Quarterly cleanup	90 days	30 days	14 days
Release hygiene	60 days	30 days	7 days
Strict launch gate	30 days	14 days	0 days

A nonzero stale-age override may be 14 to 730 whole days; a nonzero usage-window override may be 7 to 180 whole days. Stale age is inclusive: age greater than or equal to the active threshold is stale. Last-seen age must be greater than the usage window to count as old, while a 30-day check count of zero immediately counts as no recent usage. Expiry is hard only when days past expiry are greater than the grace window.

Rule Core

Decision rules are evaluated in the order below. The first matching row determines the lane and priority; stronger conditions therefore prevent later cleanup shortcuts.

Ordered feature flag cleanup decisions
Order	Decision	Condition	Priority
1	Archived	Lifecycle already indicates archived, deleted, or removed.	0
2	Dependency block	Dependencies are greater than zero and the flag is expired, unused, completed, stale, or has zero code references.	95
3	Resolve rollout state	Expiry is beyond grace while rollout is greater than 0% and less than 100%.	90
4	Archive candidate	Not permanent, code references equal zero, and no recent usage, completion, hard expiry, or stale uniform rollout supports retirement.	78 for hard expiry or no usage; otherwise 66
5	Remove code	Not permanent, code references are greater than zero or unknown, and the same cleanup evidence supports retirement.	82 for hard expiry or no usage; otherwise 70
6	Owner review	Owner is missing and owner-gap escalation is enabled.	62
7	Add cleanup date	A non-permanent, non-archived flag has no valid expiry date.	54
8	Permanent review	Permanent review is enabled and a permanent control meets the stale-age rule, lacks an owner, or lacks useful notes.	44
9	Monitor rollout	Rollout is partial or lifecycle is active without a completed state.	12
10	Current	No earlier decision matches.	0

Rollout values are clamped to 0% through 100%. Familiar all-true, all-false, enabled, disabled, launched, completed, inactive, permanent, permission, entitlement, kill-switch, and operational terms also influence lifecycle, rollout, or permanent-control classification. Missing usage data creates a lifecycle-data-gap reason but does not by itself prove no usage.

Formula Core

The hygiene index averages decision priority across all parsed flags, multiplies that average by 1.1, subtracts it from 100, rounds to the nearest whole point, and limits the result to 0 through 100.

H = clamp (round (100 - 1.1 \times \frac{\sum_{i = 1}^{n} p_{i}}{n}), 0, 100)

Here, p is the priority assigned by the first matching decision and n is the number of parsed flags. Because policy windows and optional review switches change decisions, comparisons are meaningful only when those settings and the reference date stay fixed.

Limitations and Privacy Notes:

The inventory text and loaded file are processed in the current browser. The check does not connect to a feature-flag service, search source repositories, inspect SDK defaults, verify evaluation telemetry, resolve dependency graphs, or compare environments. Treat owner names and internal flag keys as potentially sensitive. Every archive or delete decision still needs live platform evidence, code review, fallback testing, and an environment-by-environment rollback plan.

References:

OpenFeature introduction and feature-flag concepts, OpenFeature.