Feature flags — also called feature toggles — are conditional switches in your code that turn functionality on or off without a new deploy. The core idea is simple but powerful: separate the act of deploying code from the act of releasing a feature to users. Once those are decoupled, you can ship dark, roll out gradually, and turn off a broken feature in seconds instead of scrambling for a rollback.
What changed in 2026
- Flags became a platform, not a hack. Mature management systems now handle targeting, audit logs, and automatic cleanup, moving flags out of scattered if-statements and config files.
- AI-assisted flag hygiene arrived. Tooling can now surface stale toggles and suggest removals, addressing the biggest long-term cost: flag debt.
- Progressive delivery went mainstream. Percentage rollouts, targeting rules, and automatic rollback on error-rate spikes are now expected parts of the release process, not advanced techniques.
Types of feature flags
Not all flags are the same, and mixing them up causes messes:
- Release flags hide unfinished work so it can ship to production dark. Short-lived.
- Experiment flags split traffic for A/B tests. Live for the length of the experiment.
- Ops flags act as kill switches for risky subsystems. Can be long-lived.
- Permission flags expose features to specific plans or user segments. Often permanent.
Knowing which type you are creating tells you how long it should live and who should control it.
Flag types at a glance
| Type |
Lifespan |
Controlled by |
Example |
| Release |
Days to weeks |
Engineering |
Ship a redesign dark |
| Experiment |
Weeks |
Product / data |
A/B test a checkout flow |
| Ops (kill switch) |
Long |
On-call / SRE |
Disable a flaky integration |
| Permission |
Permanent |
Product |
Gate a premium feature |
Why teams use them
The payoff is control. You can deploy code to production continuously while keeping features hidden, then release to 1%, 10%, and 100% of users while watching metrics. If something breaks, you flip the flag off instead of rolling back a deploy. This pairs naturally with continuous delivery — flags are what make CI vs CD practical, because they let you merge and deploy small increments safely. They also enable trunk-based development, since incomplete work can live behind an off flag on the main branch.
Common pitfalls
- Flag debt. Flags that outlive their purpose turn code into a maze of dead branches. Every release flag needs a removal date.
- Testing only one path. Each flag doubles the number of code paths. Test both the on and off states, especially for combinations.
- Putting secrets or business logic in flags. Flags are switches, not a configuration database or an authorization system.
- No audit trail. In a shared system, an untracked flip can cause an outage nobody can explain. Log who changed what.
FAQ
What is the difference between a feature flag and a config value?
A flag is a targeted on/off switch tied to releasing behavior, often with per-user targeting. A config value tunes settings. They overlap, but flags carry rollout and targeting logic.
Do feature flags slow down my code?
Negligibly if evaluated locally with cached rules. The cost comes from complexity and untested paths, not runtime speed.
How do I avoid flag debt?
Give every temporary flag an owner and an expiry, track them in your management tool, and remove them as soon as the feature is fully rolled out.
Can feature flags replace deployments?
No — they complement them. You still deploy code; flags just control when that code becomes visible to users.
Where to go next