Types of Feature Flags

Why a taxonomy is worth your time

Every feature flag is the same if statement in code, so it is tempting to treat them all alike. That is a mistake. The useful question is not “what does this flag do” but “how long should it live and who owns it.” Those two answers differ wildly across flags, and getting them wrong is the single biggest reason flag inventories rot.

The categorization used across the industry comes from Pete Hodgson’s writing and is now baked into most platforms. There are four types, sorted roughly from short lived to long lived: release, experiment, operational, and permission flags. Two axes matter for each - how dynamic it is (does the value change per request or stay fixed for a release) and how long lived it is. Let us take them in turn.

Release flags

A release flag guards new, in progress, or not yet finished code. Its whole job is to let you merge and deploy work that is not ready to be seen, then turn it on when it is. This is the type that makes trunk based development and continuous delivery possible.

Owner: the engineering team shipping the feature.
Lifespan: days to a couple of weeks. Short.
Dynamism: low. The value is usually the same for everyone once the rollout completes.

The defining rule for release flags is that they are temporary. A release flag is a scaffolding you erect around a change and tear down once the change is load bearing on its own. When you finish a rollout, you delete the flag and the dead branch it guarded. A codebase full of aged release flags is the classic feature flag anti pattern, and how to clean up feature flags exists precisely because so many teams let this slide.

Experiment flags

An experiment flag splits traffic between variants so you can measure which performs better. Half your users see button copy A, half see B, and you compare conversion. Mechanically it looks like a release flag with a percentage split, but its purpose and owner are different.

Owner: product, growth, or data - whoever holds the hypothesis.
Lifespan: the length of the experiment, usually one to a few weeks, then removed once you have a statistically significant result.
Dynamism: high. Each user is deterministically bucketed into a variant, and the assignment must be stable so the same user keeps seeing the same variant.

Experiment flags are where a flag platform overlaps with an experimentation platform. Tools like Statsig and Optimizely treat the flag and the statistical analysis as one product, so bucketing, exposure logging, and significance testing come built in. If you plan to run real A/B tests rather than eyeball two options, you want that measurement layer rather than a raw on/off switch.

Operational flags

An operational flag, often called a kill switch or ops toggle, controls a system’s behavior in production - usually to protect availability. It might disable an expensive recommendation widget under heavy load, or cut over to a degraded but stable code path when a dependency is failing.

Owner: operations, SRE, or the on call engineer.
Lifespan: long, sometimes the lifetime of the system. This is the exception to “flags are temporary.”
Dynamism: varies, but often a simple global on/off that someone flips during an incident.

The kill switch is the flag type most worth keeping around, because its value shows up exactly when things are on fire. Being able to disable a misbehaving subsystem in seconds, without a redeploy, is the difference between a blip and an outage. What is a kill switch goes deeper on the pattern, and Harness FME and LaunchDarkly both emphasize this operational safety use case in their positioning. Because these flags are permanent, they should be named and documented so nobody mistakes them for stale release flags and deletes them.

Permission flags

A permission flag - also called an entitlement or access flag - changes what a feature exposes based on who the user is. Premium tier users see the advanced dashboard, beta customers get early access, internal staff see debug tools. Unlike the others, this flag is a product decision, not a delivery mechanism.

Owner: product, tied to your plans and packaging.
Lifespan: very long, often permanent, because your pricing tiers are permanent.
Dynamism: high. The value is computed per user from their plan, role, or entitlements on every request.

Permission flags blur into your billing and authorization logic. That is fine, but be aware that if entitlements are the only thing you use flags for, a full flag platform may be more than you need - a plan check in your own code can do the job. Where flags shine is when the same infrastructure that gates premium features also handles your betas and gradual rollouts. Flagsmith and other platforms support this by attaching traits to identities and targeting on them.

Putting the taxonomy to work

The payoff of naming these types is operational discipline. Two habits follow directly:

Encode the type in the name. A convention like release-new-checkout versus ops-disable-recommendations versus perm-advanced-analytics tells any reader the flag’s intent and expected lifespan at a glance. Feature flag naming conventions lays out a full scheme; the point is that the type should never be a mystery.

Set expiry expectations per type. Release and experiment flags get an owner and a removal date at creation. Operational and permission flags are explicitly marked as long lived so cleanup automation skips them. Many platforms surface flag age and last evaluated time exactly so you can spot a release flag that has overstayed. Combined with the broader feature flags best practices, this is what keeps an inventory from ballooning into hundreds of flags nobody dares touch.

Key takeaways

There are four flag types: release (temporary, eng owned), experiment (measured, product owned), operational / kill switch (long lived, ops owned), and permission (permanent, tied to plans).
The type determines lifespan and owner, not the code - that is why it matters.
Release and experiment flags are meant to be deleted after they serve their purpose; operational and permission flags are meant to stay.
Encode the type in the flag name and set removal expectations at creation.
Mixing types in one flag is what leads to flags nobody is willing to clean up.

You now know what kinds of flags exist. The next chapter gets into the mechanics that make release and experiment flags powerful - how targeting rules and percentage based rollouts let you release to the right users gradually and safely. Continue to targeting and progressive rollouts.