A feature flag stayed in the codebase two years after the feature fully shipped. Cleaning it up caused the outage.
Give every feature flag an owner and an expiry date at creation, or it becomes permanent untested config.
architectureopsfeature-flags
Problem
Teams end up in one of two states with feature flags: afraid to use them (so every release is a risky big-bang deploy), or drowning in them (dozens of stale flags nobody remembers the purpose of).
Why it happens
Flags get created with urgency and removed with none. There’s a clear reason to add one (you want a safe rollout), but no equivalent trigger to delete it once the rollout finishes, so it just sits there as permanent, untested config.
Better approach
Treat every flag as one of three types, and give it an owner and an expiry at creation:
- Release flags: temporary, deleted once rollout hits 100%
- Experiment flags: temporary, deleted once the experiment concludes
- Ops flags: permanent kill switches, explicitly reviewed on a schedule
If a flag doesn’t fit one of those categories, it shouldn’t exist.
Example
A payment-related release flag left flipped “on” in code for two years after the rollout finished. Nobody remembered what it gated. Removing it during a cleanup pass turned out to be the one line holding checkout together.