Feature Flag Naming Conventions That Survive Contact With Reality (2026)

Every flag list starts clean. Then a year passes and you’re staring at newCheckout, newCheckout2, newCheckout_final, temp_fix, test, and a flag literally called asdf that’s been in production for eight months and nobody will touch.

Naming conventions aren’t bureaucracy. They’re the difference between a flag list you can read and one you’re afraid of. Here’s a convention that scales to hundreds of flags, and the reasoning behind each rule.

Why naming matters more than you think

A feature flag isn’t just a switch. It’s a promise that someone, someday, understands it well enough to flip it or delete it. At 10 flags, memory covers you. At 300 flags across a dozen teams, the name is the only documentation most people will ever read.

Tools don’t save you here. Flagsmith gives unlimited flags on every tier, Unleash and LaunchDarkly impose no meaningful cap either - so nothing in the product forces you to keep the list clean. That’s a feature, but it means sprawl is your problem to prevent. The name is your first and best defense.

The four things a good name encodes

A flag name should answer four questions on sight. Type, scope, what it does, and who owns it.

1. Type - what kind of flag is this? Flags fall into a few well-known categories, and they have very different lifetimes:

• Release toggles - hide unfinished work, removed after the feature ships. Short-lived.
• Experiment toggles - drive an A/B test, removed when the test concludes. Short-lived.
• Ops toggles (kill switches) - turn a risky subsystem off in an incident. Long-lived, sometimes permanent.
• Permission toggles - gate features by plan or entitlement. Permanent.

Prefixing by type tells everyone the flag’s expected lifetime immediately. release-* should disappear; perm-* should not. A reader who knows the type knows whether the flag is trash or infrastructure.

2. Scope - what part of the system? Add the service, domain or team - checkout, search, billing. This groups related flags and makes them filterable.

3. Description - what does it actually do? A short, human-readable slug. new-payment-form, not npf or v3.

4. Owner - who’s accountable? This usually lives in a tag or the flag’s description field rather than the name, but it must exist somewhere. A flag with no owner is a flag no one will ever clean up.

Put together, the pattern is roughly type-scope-description:

release-checkout-new-payment-form
experiment-search-ranking-v2
ops-billing-disable-stripe-webhooks
perm-workspace-advanced-analytics

The rules that prevent bugs

Convention isn’t only about readability. A few rules exist because breaking them causes real bugs.

Name for the positive state. enable-new-checkout, not disable-old-checkout. Negative names produce double negatives in code - if (!disableOldCheckout) is where mistakes hide. The one intentional exception is kill switches, which teams often name so that “on” clearly means “stop something” - ops- or kill- prefixes make that obvious. Pick a rule and hold it; consistency beats cleverness.

Pick one case style and never mix. kebab-case or snake_case, chosen once, documented, enforced in review. Mixing newCheckout and new-checkout and new_checkout in the same list is how you end up with two flags that look like one.

Never encode the value in the name. checkout-set-to-true is meaningless the moment someone flips it. The name describes the capability; the value describes the state. Keep them separate.

Tie to a ticket. Put the tracking ticket in the flag’s description or a tag. It gives you a place to check whether the underlying work actually shipped - which is the question you’ll ask every time you consider deleting the flag.

Encode lifetime, then actually clean up

The single most valuable thing a convention does is make stale flags visible. If release-* flags are supposed to vanish after rollout, then a release-* flag that’s six months old is a flag you can see is overdue - just by scanning the prefix.

But naming only surfaces the problem. Cleanup is a process, not a name. Because no tool forces it - unlimited flags means unlimited stale flags - you need a standing habit:

1. Tag temporary flags at creation so they’re findable later.
2. Run a periodic sweep - monthly or per-sprint - filtering by type prefix and age.
3. Assign an owner to every removal, using the ticket you tied at creation to confirm the work shipped.

Some enterprise tiers add approval workflows that can gate flag creation and enforce a bit of hygiene, but the naming standard itself lives in your team’s documentation and code review, not the vendor. The tool won’t do it for you.

A starter standard you can copy

Here’s a minimal convention that works for most teams. Adapt the prefixes, keep the structure:

• Format - type-scope-description, kebab-case, positive phrasing.
• Types - release, experiment, ops, perm. First three are temporary, perm is not.
• Every flag carries an owner and a ticket in its description or tags.
• Cleanup - a scheduled sweep that filters temporary types by age.

Write it down, link it from your onboarding docs, and enforce it in review. That’s the whole game - the convention is only worth what your team consistently applies.

For the wider practice around flags, see our feature flags best practices guide and, if you’re still standing the system up, how to implement feature flags. For the kill-switch category specifically, what is a kill switch covers why ops flags deserve their own naming rule.