Feature Flags: Types, Lifecycle, and Governance for Teams

Feature Flags: Types, Lifecycle, and Governance for Teams

Feature flags let you ship code to production without exposing it, turn it on for a few users, and turn it off in seconds if something breaks, all without redeploying. Adopting them is the easy part. Running them well, with clear types, owners, expiration dates, and a habit of deleting what you no longer need, is what separates a safety net from a second, undocumented codebase.

This article treats feature flags as a discipline. It is not a comparison of deployment strategies. For the wider release picture, see our guide to release management. Here we focus on what you need to decide before the first flag ships and what to enforce after the hundredth.

Key takeaways

• A feature flag separates deployment (code reaches production) from release (users can see it). That split is the whole value.
• Not all flags are alike. Release, experiment, operational, and permission flags have different lifetimes and different owners, and should be managed differently.
• Every flag needs an owner, a purpose, and a removal plan on the day it is created. Stale flags become technical debt, and in the worst case an outage.
• Treat flag changes in production like code changes: access control, review, audit logs, and monitoring.
• The flag service itself is a dependency. Design for the day it is unavailable.

Table of Contents

• What feature flags do, and what they do not
• Four types of feature toggles, four lifetimes
• The lifecycle of a flag, from creation to deletion
• Governance: who can change what in production
• Rollout strategies and percentage rollout
• Where feature flags go wrong
• Choosing feature flag management tooling
• How we help with feature flag programs
• Feature flags are a discipline, not a switch
• FAQ
• Sources

What feature flags do, and what they do not

A feature flag, also called a feature toggle, is conditional logic evaluated at runtime that decides whether a block of code runs for a given user. Its state can be changed through external configuration, without modifying and redeploying the application.

That gives you a clean separation. Deployment puts code in production. Release makes the feature available to users. With flags, teams can put code into production while restricting availability, then activate it for selected users without a restart or a new deploy. Teams use that separation for trunk-based development, gradual rollouts, experiments, premium access, and operational control.

Trunk-based development is worth a sentence. Because unfinished work can merge behind a flag that is off, branches stay short and integration pain drops. The price is that your main branch now carries code paths that are not live, and someone has to account for them.

What flags are not: configuration. Static application configuration is generally long-lived and loaded at startup, while flags are dynamic, short-lived, and updated at runtime. Mixing the two is how a database connection string ends up in a toggle dashboard that thirty people can edit.

How does a flag actually get evaluated? An SDK in your application fetches rules, evaluates them against the user and context, and applies the result. One documented example: a server SDK caches configuration and polls for updates every 60 seconds, with evaluations typically sub-millisecond. Fetching and resolving are separate steps, and SDKs may fetch at startup, in the background, or during a session. That detail matters later, when we get to failure modes.

Four types of feature toggles, four lifetimes

Most flag trouble starts when a team treats every toggle the same. Martin Fowler’s widely cited taxonomy of toggles separates them by how long they live and how dynamic they are. In practice, we find four working categories useful:

Release flags

These are the workhorses. They exist so incomplete code can merge and so a launch can be a business decision rather than a deploy event. They should be the shortest-lived flags you have. If a release flag is older than the feature is, something went wrong.

Kill switches

A kill switch is an instant, all-user on/off control for disabling a misbehaving feature or dependency in seconds, with no redeploy. Microsoft’s DevOps guidance notes that a quick-off flag can restore trusted behavior and can control architectural or infrastructure changes as well as user-interface features.

Kill switches are the legitimate exception to the short-lived rule. Fowler describes long-lived ones as operational toggles that let operators gracefully degrade non-vital functionality under unusually high load. His point about speed is the one to remember: if turning something off requires a new release, the toggle has failed at its only job. Put a kill switch around every expensive third-party call, every new data pipeline, and every feature that touches payments or email, then practice using them.

Experiment and permission flags

Experiment flags live exactly as long as the test. Decide the metric and the end date before the flag turns on. Permission flags are really product entitlements wearing a flag costume. If access depends on a customer’s plan, model it as an entitlement with its own tests, not as a toggle someone might delete during cleanup.

The lifecycle of a flag, from creation to deletion

Atlassian’s documentation describes a typical lifecycle of creation, targeting configuration, runtime evaluation, and cleanup. Most teams do the first three well and skip the fourth. A workable lifecycle has six stages:

1. Propose. Record the flag’s name, type, owner, purpose, and expected removal date. Names should be unique and descriptive enough that a new hire can guess what the flag does.
2. Build. Keep flag evaluation separate from business logic, so the decision sits in one thin layer rather than scattered through functions. Define a safe default for when the flag service cannot answer.
3. Test. Exercise both code paths. A flag with one tested branch is a bug waiting for its turn.
4. Roll out. Move through your chosen rollout pattern while watching error rates, latency, and business metrics.
5. Stabilize. Once the feature is at 100% and quiet, the flag has done its job.
6. Remove. Delete the flag, the losing code path, and the tests for it. Then confirm nothing references the flag in the codebase.

Steps five and six are where discipline lives. Research suggests the problem is real and not only theoretical. A 2021 empirical study of 12 Python open-source projects and a survey of 61 practitioners found that 75% of toggle components were removed within 49 weeks, which also means a meaningful share were not, and some long-lived flags were never intended to persist. Those survivors are the ones that quietly add risk.

Preventing flag debt

Flag debt is the accumulation of toggles that no longer serve a purpose but still shape what the code does. The arc42 quality model lists toggle debt, stale test states, and collisions between interacting toggles among the failure modes of the approach. A few habits keep it in check:

• Expiration dates in the flag record. Alert the owner when a flag passes it, and again when it is overdue.
• A cleanup ticket created with the flag. Not later. When the rollout ticket closes, the removal ticket is already waiting.
• A cap on active release flags per team. A number everyone can see creates healthy pressure.
• A periodic code sweep. Harness recommends stale-flag alerts and checking code for remaining flags, which a CI check can automate.

If your team already carries a backlog of dead code, the same prioritization approach applies. Our guide to technical debt remediation covers how to size and sequence that work.

Governance: who can change what in production

A flag change in production is a production change. Harness advises treating feature-flag configuration as production code, with comparable review controls, graceful degradation using cached or default values, and backward compatibility. The practical version for an engineering leader looks like this:

• Role-based access. Not everyone who can read flags should be able to flip them in production. LaunchDarkly lists granular role-based access control and audit logs as safety capabilities for controlled production changes.
• Approvals for high-risk flags. Payments, authentication, and data deletion deserve a second pair of eyes before a flag changes.
• Audit logs. You should be able to answer who changed what, and when, without asking around in chat.
• Environment discipline. Staging and production configuration drift is a documented failure mode, so compare them on a schedule rather than hoping.
• Clear naming and ownership. An ownerless flag is a future incident with no one to call.

Security is part of governance

Flags can weaken security if you are careless. OWASP’s testing guide warns that inconsistent flag states can weaken authentication, authorization, fraud detection, and rate limiting across services, especially during partial rollout, rollback, or flag-service failure. It also warns that client-visible flags are not security boundaries. Enforce authorization on the server, evaluate sensitive flags server-side, and never rely on a hidden button as a control. If your application handles regulated data, involve your security lead before the first flag touches an access path.

Rollout strategies and percentage rollout

Flags make several rollout patterns possible, and the right one depends on your user base. LaunchDarkly’s documentation describes ring releases, percentage releases, canaries, targeted releases, entitlement releases, and dark launches. In plain terms:

• Ring release: internal staff first, then a beta group, then everyone. Good when you have a natural beta audience.
• Percentage rollout: expose 1%, then 5%, then 25%, and so on. Best suited when the user base has little variation or you have no beta program.
• Canary: a small, representative group to test acceptance and capacity.
• Targeted release: specific accounts or groups, useful when customers depend on each other.
• Dark launch: the code is deployed and exercised, but not publicly released.

Azure’s rollout model adds useful dimensions: targeting by user, group, or custom attributes such as region, device type, or subscription tier, plus scheduled activation. AWS frames the logic well: limiting the blast radius while testing under real-world conditions beats exposing every user at once.

Two rules make percentage rollout trustworthy. First, keep assignment consistent, so a user who sees the new checkout today does not see the old one tomorrow. Second, write down in advance what you will watch and what result triggers the kill switch. A rollout without a stop condition is just a slow launch.

GitHub describes enabling risky changes for everyone or a percentage after deployment and then disabling them in seconds without rolling back. That only works if you can see the effect quickly, which is why flags and monitoring go together. Our piece on application observability covers what to instrument.

Where feature flags go wrong

The downsides are specific, and they are worth knowing before you commit.

Stale code and unsafe reuse. InfoQ’s account of the 2012 Knight Capital incident describes an obsolete flag being reused while dead code remained. The result was roughly $460 million in losses in about 30 minutes. Two lessons: delete dead code, and never repurpose an old flag name for new behavior.

Combinatorial complexity. Every flag doubles the theoretical number of code paths. You will not test them all, so keep interacting flags to a minimum and document dependencies between them. GitHub also lists specific risks such as slower database queries, unexpected logic edge cases, and invalid database values.

The flag service as a single point of failure. PostHog’s incident report records that 78% of feature-flag evaluation requests in its US region failed for 1 hour 48 minutes, with retry amplification and weak health checks prolonging it. A later postmortem covers four incidents over 10 days that affected the main application as well as flag evaluation. The lesson for your own systems: local caches and fallback defaults keep applications running when the flag system does not, as best-practice guidance notes. Test what your app does when flag evaluation times out. Do not discover it in production.

Inconsistent evaluation. The same flag can resolve differently within a single request if it is read twice. Evaluate once at the edge of the request and pass the result along.

Choosing feature flag management tooling

Building a basic flag system is a weekend project. Operating one safely for years is not, so decide with your eyes open. When you assess platforms or an in-house build, LaunchDarkly’s own capability list is a useful checklist: SDK coverage, Boolean and multivariate flags, targeting and segmentation, progressive rollouts, environment gating, prerequisites, real-time updates, kill switches, RBAC, approvals, audit logs, and integrations.

Beyond that list, ask these questions:

1. What happens when the service is down? Look for local caching and documented fallback behavior. One vendor’s pricing page, for example, describes SDKs that download and cache configuration and evaluate from that cache.
2. How fast do changes propagate? Seconds or minutes? Does the polling interval match your kill-switch expectations?
3. Can you manage flags as code? UI, CLI, API, and Git workflows matter once you have more than a few dozen flags.
4. Does it help you clean up? Stale-flag reporting is worth more than another targeting option.
5. Where does user data go? Evaluating flags server-side keeps personal data out of third-party systems.

For small teams with a handful of release flags, a simple in-house approach with strict naming and expiry can be enough. As teams, services, and compliance needs grow, managed platforms earn their cost. The right answer depends on your architecture, and it is a good question to settle before you have two hundred flags.

How we help with feature flag programs

At Ridiculous Engineering, senior engineers work with your team on the decisions around feature flags: which flag types you need, how to wire evaluation into your architecture, what governance fits your risk profile, and how to build cleanup into your delivery pipeline. If you are modernizing a legacy system or building something new, our software consulting and delivery support and custom software development engagements are scoped to your situation, with pricing on request. You can also browse our DevOps articles for related practices.

Feature flags are a discipline, not a switch

Feature flags give you something rare: the ability to ship continuously and still retreat in seconds. They keep that promise only when each flag has a type, an owner, a test for both paths, an audit trail, and an end date. Treat the flag system as production infrastructure, keep kill switches for the moments that matter, and delete everything else on schedule.

Start small. Pick one upcoming feature, assign an owner, write the removal ticket first, and run it through the full lifecycle. What your team learns from that one flag will shape every policy that follows.

FAQ

What is the difference between feature flags and feature toggles?

Nothing meaningful. The terms are used interchangeably, and Martin Fowler’s well-known article uses both. Some teams reserve toggle for simple on/off switches and flag for ones with targeting rules, but that is a house convention rather than a standard.

Are feature flags the same as configuration?

No. Configuration is generally long-lived and loaded at startup, while flags are dynamic, short-lived, and changed at runtime. Keeping them separate prevents sensitive settings from ending up in a tool built for frequent, low-friction changes.

What are the downsides of feature flags?

The main ones are stale flags that become technical debt, extra code paths that multiply testing effort, and dependence on the flag service. Security is a further concern if flags guard access controls. Owners, expiry dates, safe defaults, and server-side evaluation address most of these.

When should a kill switch live permanently?

Keep it when it protects against a recurring operational risk, such as an unreliable third-party dependency or a heavy feature under peak load. Document it, test it periodically, and give it an owner like any other long-lived control.

Sources

• Feature flags - .NET | Microsoft Learn
• Feature flags core concepts | Atlassian
• What are feature flags? | Confidence Documentation
• Feature Toggles (aka Feature Flags) | Martin Fowler
• Understand feature management using Azure App Configuration | Microsoft Learn
• Progressive experimentation with feature flags | Microsoft Learn
• 11 best practices for building and scaling feature flag systems | Unleash
• On the Removal of Feature Toggles (2021)
• Feature Toggles | arc42 Quality Model
• Best Practices for Managing Flags | Harness
• Best practices for effective feature flag management | Harness
• Feature flag security bypass | OWASP Web Security Testing Guide
• Deployment and release strategies | LaunchDarkly
• How feature flags work | LaunchDarkly
• Implement incremental feature release techniques | AWS Well-Architected
• How we ship code faster and safer with feature flags | GitHub
• When Feature Flags Go Wrong | InfoQ
• Feature flags service outage | PostHog
• Feature flags recurring outages | PostHog
• Pricing | ConfigCat

Recommended

• Release Management: How Engineering Teams Ship Changes Safely
• Optimize Your DevOps Practices with Expert Insights and Tools