Feature flags come in four common types: release, experiment, ops and permissioning. Release flags should usually be removed within weeks, experiment flags last as long as the test needs, ops flags are often short but some stay, and permissioning flags can live for years.
The four types
Martin Fowler's article on feature toggles sorts them by how long they live and how dynamic their decisions are. The categories are useful because each one implies a different cleanup rule.
Release flags
These let incomplete and untested code ship to production while staying off. Fowler says they are transitory and should generally not stick around much longer than a week or two, though product-centric ones may last longer. If you still have one after a quarter, the likely answer is that it is finished and nobody removed it.
Experiment flags
These support A/B and multivariate tests by consistently routing each user to a cohort. They must stay fixed long enough for statistically significant results, which Fowler puts anywhere from hours to weeks. Their routing is highly dynamic, because it depends on the individual user. When the test ends, pick the winner, delete the loser and delete the flag.
Ops flags
These control operational behavior so operators can disable or degrade features during production issues. Most are short lived, but some may last almost indefinitely. Long-lived ones are kill switches, covered in kill switch design.
Permissioning flags
These change which users get which features, such as premium or beta access. They can be very long lived, sometimes years, and are evaluated per request. Because they decide who can do what, review them like access control code.
A simple tagging scheme
Add two fields to every flag record: type and owner. Then your cleanup review has a clear rule.
- Release: review weekly, expect removal.
- Experiment: review at the planned end date.
- Ops: review each quarter, keep only the kill switches you can explain.
- Permissioning: review with your access reviews.
Why this matters for security
Old flags leave dead code behind that nobody tests. A path that is switched off but still present can be switched on by mistake, or by someone with more access than they should have. Fewer flags means a smaller set of states to reason about.
Quick check
How many flags are too many?
Fowler suggests capping the number of active toggles, so adding one means removing another. Pick a number your team can review, and enforce it.
Sources
Last reviewed: 19 October 2026.
