Product and engineering teams preparing a quarterly feature-flag cleanup review.
How to structure a flag audit so cleanup decisions retain ownership, code, targeting, and customer evidence.
The minimum useful feature flag audit fields
Copy these columns into a spreadsheet or export them from your flag platform. Keep source fields unchanged and add normalized review fields beside them.
- Flag key, project, environment, type, created date, and last changed date.
- Product owner, engineering owner, release or experiment reference.
- Variations, default, targeting rules, and account assignments.
- Evaluation activity window and environment coverage.
- Production code references and known test dependencies.
- Affected accounts, recurring revenue, and contractual constraints.
- Decision, rationale, delivery owner, due date, and blocking event.
Use six decision states
Avoid a vague stale checkbox. A decision state should tell the team what action or evidence is required next.
- Remove now.
- Complete rollout, then remove.
- Investigate ownership or dependencies.
- Preserve as a governed operational control.
- Convert to long-lived product configuration.
- Retire after a named contract, renewal, migration, or release event.
Run the review in two passes
In the first pass, engineering validates code references, evaluation activity, and safe-removal conditions. In the second, Product and customer owners validate behavior, account dependency, and commercial timing.
Do not ask a large committee to review every field together. Resolve high-confidence removals quickly and route uncertain flags to the smallest group capable of establishing the missing evidence.
What to report after the audit
Publish the source date and coverage beside the result. Report removals separately from rollout work, investigations, preserved controls, conversions, and event-blocked retirements.
- Total flags reviewed and percentage with an owner.
- Flags approved for immediate removal.
- Flags requiring rollout, migration, or code work.
- Unknown flags requiring investigation.
- Long-lived controls with documented review criteria.
- New flags created and old flags resolved since the prior audit.
Evidence base
Sources and further reading
Practical answers
Frequently asked questions
How often should we run a feature flag audit?
Quarterly is a practical default. Run it more often when the team creates flags rapidly or before a major platform migration.
Can a spreadsheet handle the audit?
Yes for an initial review. A ledger becomes useful when assignments, revenue, source coverage, and decisions must be refreshed and preserved over time.
Should an old flag always be removed?
No. Age is one signal. Operational controls, entitlements, and customer configuration can be intentionally long-lived.
What makes a removal high confidence?
No relevant production code dependency, no active targeting or evaluations, a known default outcome, and no unresolved customer or contract dependency.