Cleaning Up Feature Flags Before They Clean Up You

Set an expected removal date the moment a flag is created, not as an afterthought once someone notices it's stale. A permanent flag, one genuinely meant to live indefinitely for something like a kill switch, should be explicitly marked as such, so it's excluded from cleanup sweeps instead of showing up as clutter every time someone reviews the list.

This single habit does more to prevent flag debt than any cleanup process applied after the fact, because it turns removal into a planned step instead of a discovery.

A flag that's been fully rolled out to everyone, or fully rolled back to no one, for months is no longer actually a flag, it's dead code wearing a flag's clothing. Pull a report of every flag's current rollout percentage and how long it's been stable at that percentage, and treat anything unchanged for an extended period as a cleanup candidate.

This audit is usually the fastest way to find the bulk of your flag debt, because most stale flags aren't ambiguous once you look, they're just sitting fully on or fully off and nobody's gotten around to deleting the code.

Some flags legitimately need to stay partially rolled out for a while, a gradual regional expansion or a slow migration, so check the trend, not just the current number, before flagging something as stale. A percentage that's been climbing steadily is different from one that's been frozen for months.

Confirm the flag's current state in production matches what you're about to hardcode before deleting anything, since removing a flag is effectively a deploy of whatever state you assume it's in. Delete both the flag definition and every conditional branch tied to it, not just the flag configuration, or you'll leave dead, unreachable code behind that looks like it's still doing something.

Remove flags in small batches with normal code review, the same as any other change, rather than as a big end-of-quarter cleanup sprint that tries to touch everything at once.

Feature flags exist partly to decouple deploying code from releasing behavior, which is a big part of what lets a team safely increase its deploy frequency. But that benefit erodes as stale flags pile up: each one adds a conditional branch every future change has to reason around, which drags directly on the same deploy frequency the flags were meant to help improve¹.

Treat flag count as a health metric worth watching, not just a list to clean up eventually. A steadily growing count of long-lived flags is a sign the cleanup habit isn't keeping pace with flag creation, and that gap tends to widen on its own once it starts, since more flags make every future cleanup pass slower and more error-prone.

A flag with no clear owner tends to outlive the reason it was created, because nobody feels responsible for closing the loop once the rollout is done. Assign an owner at creation, the same engineer or team who added the flag, and make flag cleanup part of what closes out the related project, not a separate task competing for attention later.

A short recurring review, even fifteen minutes on a regular cadence to check the stale-flag report, keeps this from becoming a large, dreaded cleanup project down the line.

A short flag hygiene checklist:

• Set an expected removal date when each flag is created, and mark genuinely permanent flags, such as kill switches, so cleanup sweeps skip them.
• Assign an owner at creation, the engineer or team who added the flag, and make cleanup part of closing out the related project.
• Pull a report of rollout percentages and treat any flag unchanged for an extended period as a cleanup candidate.
• Before deleting, confirm production state matches what you will hardcode, then remove the flag definition and every conditional branch tied to it.