How to Use Feature Flags: 7 Steps From First Flag to Removal

Feature flags, also called feature toggles, are switches in code whose value comes from configuration at runtime, so a team can change which code path a user gets without deploying new code. This guide uses feature flags in 7 steps: pick the flag type, put the decision in one place in code, define targeting, roll out by percentage, record every change, check which value a customer received at a past time, and remove the flag when its job is done.

The steps apply to server-side and client-side flags in a web service. The steps do not cover experiment analysis, which needs its own sample-size and metric design.

What feature flags mean

A feature flag is a conditional in code whose branch is chosen by a rule outside the code. Pete Hodgson’s article Feature Toggles (aka Feature Flags) on martinfowler.com (October 9, 2017) describes toggles as a technique that lets a team modify system behavior without changing code, and sorts toggles into four categories by how long each one lives and how often its value changes.

Category	What the flag controls	Lifetime in Hodgson’s article
Release toggle	Whether incomplete or unreleased code is reachable in production	Transitionary, removed after the release
Experiment toggle	Which variant each user sees in an experiment	Long enough to reach an experiment result
Ops toggle	Operational behavior, such as switching off a costly feature under load	Mostly short-lived, with some long-lived kill switches
Permissioning toggle	Which users can use a feature, such as internal or paying users	Long-lived

The category decides who owns the flag and when the flag leaves the code. A release toggle that stays for a year has turned into a permissioning toggle without anyone deciding it.

Before you add a feature flag

Six inputs decide whether a flag stays manageable after the first week.

• The question the flag answers: release, experiment, operations, or permission.
• The attributes the rule needs, such as customer, user key, plan, and region.
• The safe default value the code uses when no flag value is available.
• An owner and a planned removal date for every release and experiment flag.
• The environments the flag exists in, such as development, staging, and production.
• The signal that says a rollout is healthy, such as the error rate or the latency of the flagged code path.

How to use feature flags in 7 steps

1. Pick the flag type before writing code

Choose the category from Hodgson’s four before adding the flag, because the category sets the lifetime and the owner. A release flag belongs to the team shipping the feature and has a removal date. An ops flag belongs to the team that runs the service and can stay for years as a kill switch. Hodgson describes long-lived ops toggles as manually managed circuit breakers, such as switching off a costly recommendation panel when the site is under heavy load.

2. Put the flag decision in one place in your code

Wrap each flag check in one function named after the decision, such as canUseInvoiceExport(customer), instead of repeating the flag key and the rule across files. Hodgson recommends separating decision points in the code from the decision logic behind them, so a change to the rule does not touch every caller. The function also gives the team one place to delete when the flag retires in step 7.

3. Define targeting rules on customer attributes

A targeting rule maps attributes to flag values, such as serving the new path to enterprise-plan customers in one region. In Loglune, the evaluation attributes are the customer, the user key, and the other attributes the code passes in, and Loglune converts targeting conditions into JSONLogic expressions. Loglune treats a greater-than or less-than comparison between values of different types as false, and treats an exception during evaluation as false as well.

4. Roll out by percentage with a deterministic hash

A percentage rollout serves the new value to a share of users and keeps each user in the same bucket across requests. The flagd fractional operation (checked September 16, 2026) assigns variants deterministically by relative weight using a MurmurHash3 (murmur3) hash, and lists A/B testing, experimentation, and gradual releases among its uses. Loglune uses the same MurmurHash3 hashing as the flagd fractional operation and compares each hash against cumulative weights, so a customer’s bucket stays the same across Loglune SDK languages and versions.

The variant order and the weights together set the bucket boundaries. Raise the percentage in stages such as 1%, 10%, 50%, and 100%, and keep the variant order fixed while the rollout runs.

5. Record every flag change with who, when, and what changed

Every edit to a flag rule changes what customers receive, so every edit needs a record. In Loglune, a flag edit in the console or through the API is appended to the change history as a change event that records the customer, the actor, the time, the target flag, and the values before and after the edit. Publishing a draft in Loglune creates an immutable version, and each customer’s versions carry a serial number that increases with every publish.

The change history in Loglune is append-only, and Loglune derives the current flag state by rebuilding the full history. Loglune does not connect to other flag platforms, so the history covers the flags defined in Loglune.

6. Check which value a customer received at a past time

A customer report arrives hours after the fact, and by then the flag rule may have changed. The Loglune SDK evaluates the delivered version in your own process or at the edge and returns each flag value together with an evaluation record containing the version, the attribute key, and the returned value. A support ticket or error report can carry that record.

To reproduce the customer’s flag state, pick the customer and the time T, or import the evaluation record from the report. Loglune rebuilds the flag state at T and delivers it in reproduction mode to a development, CI, or staging environment, and one delivery counts as one reproduction. Time-based conditions are evaluated at T. Loglune reproduces the flag evaluation, not the root cause in application code, and the Free plan includes 5 reproductions (pricing).

7. Remove the flag when its job is done

A flag that has finished its job still costs maintenance. Hodgson describes a carrying cost for each toggle and says savvy teams treat toggles as inventory and keep that inventory low. Once a release flag serves one value to every customer, delete the flag check and the unused code path, then retire the flag. Experiment flags leave the code when the experiment decision is made, and ops and permissioning flags get a scheduled review instead of a removal date.

Feature flag management: owners, lifetimes, and cleanup

Feature flag management is the routine that keeps the flag inventory small and every flag owned. The table sets one owner and one review trigger per category, following the lifetimes in Hodgson’s article.

Category	Owner	Review trigger	Removal
Release	Team shipping the feature	Rollout reaches 100%	Delete the check in the next sprint
Experiment	Team running the experiment	Experiment decision made	Delete the losing path
Ops	Team running the service	Scheduled review	Keep while the kill switch is needed
Permissioning	Product owner of the access rule	Plan or pricing change	Keep while the access rule exists

Feature flag software and platforms: what to compare

Feature flag software and feature flag platforms differ on a handful of axes that the 7 steps expose. Compare where evaluation runs (inside your process or on a remote service), whether bucketing is deterministic across SDK languages, what the change history records, whether the platform can rebuild the flag state a customer received at a past time, which SDK languages exist, and how the price scales with seats, requests, or reproductions. A comparison of feature flag platform alternatives by past-state reproduction applies these axes to named products.

Loglune fits a team that wants to answer which value one customer received at a past time. Loglune does not connect to other flag platforms, so a team moving from another platform defines its flags in Loglune before the change history starts.

Editorial example (not a customer case): one flag from creation to removal

The table follows one release flag, invoice-export, through its life. Dates, percentages, and names are illustrative.

When	Action	Flag rule after the action	Record
Monday	Flag created with default off	Off for every customer	Change event and version 1
Tuesday	Internal team targeted	On for the internal team	Change event and version 2
Wednesday	Rollout started	On for enterprise plan, 10% of others	Change event and version 3
Thursday, 2:05 p.m.	Customer reports a broken export	Unchanged	Evaluation record attached to the report
Thursday, 3:00 p.m.	Flag state at 2:05 p.m. rebuilt	Unchanged in production	One reproduction in staging
Following Monday	Rollout at 100%	On for every customer	Change event and version 4
Two weeks later	Flag check deleted from code	Flag retired	Removal task closed

On Thursday, the team reads the evaluation record, sees version 3 and the customer’s attribute key, and rebuilds that state in staging instead of guessing which bucket the customer was in.

Troubleshooting feature flags

• A user sees different values on two devices: check which key the rollout hashes, because a device identifier and an account identifier put the same person in different buckets.
• Users flip between values after a weight change: check whether the variant order changed, because cumulative weights move the bucket boundaries.
• A flag value is missing at startup: make sure the code falls back to the safe default from the inputs list.
• A customer reports a bug and nobody knows the flag state at the time: read the evaluation record from the report and rebuild the flag state at the reported time.
• Old flags have no owner: assign owners by category using the management table, and remove release flags that already serve one value to everyone.
• A reproduction of a time-based rule shows a different value than the rule serves today: Loglune evaluates time conditions at the reproduced time T, not at the current time, so the reproduced value follows the rule as it stood at T.

FAQ

Is a feature flag the same as a feature toggle?

A feature flag and a feature toggle are two names for the same technique. Hodgson’s article is titled Feature Toggles (aka Feature Flags) and uses toggle as the main term.

Are feature flags the same as A/B tests?

A/B tests are one use of feature flags, not a synonym. An experiment toggle assigns variants, and the analysis of which variant performed better happens in a separate analytics tool. Loglune assigns variants and does not analyze experiment outcomes.

How many feature flags are too many?

No fixed number marks too many feature flags. Hodgson treats every toggle as a carrying cost, so the working limit is the number of flags the team can own, review, and remove on schedule.

Do feature flags replace canary or blue-green deployments?

Feature flags do not replace canary or blue-green deployments, because the two work at different layers. Martin Fowler’s note on blue-green deployment (March 1, 2010) switches traffic between two production environments, and a canary sends a share of traffic to a new version. A feature flag switches code paths inside one running version.

Deciding when a feature flag is worth adding

Add a feature flag when the team needs to separate deploy from release, run an experiment, switch off a costly path under load, or gate access by plan. Skip the flag for a change that is small enough to ship complete and safe to roll back with a deploy. Every flag that is added gets a category, an owner, a removal plan, and a change history, so the team can answer which value a customer received at the moment a bug fired.