What is a percentage rollout?

A percentage rollout splits traffic across feature flag variations by percentage. For example, you might serve the new feature to 20% of users and the existing behavior to the remaining 80%. Featureflip uses a deterministic hashing algorithm that combines the user's ID with the flag key to produce a stable bucket assignment. This means the same user always gets the same variation for the same flag — they will not flip between true and false on page refresh, across devices, or between API calls. This consistency is critical for a good user experience and for drawing reliable conclusions from experiments. When you adjust the percentage — say, from 20% to 50% — users already in the 20% group stay in it; only new users are added. Different flags hash independently, so a user in the 20% bucket for one flag is not necessarily in the 20% bucket for another.

How do I gradually release a feature to users?

Start at 5% and monitor your error rates, latency, and key business metrics. If everything looks healthy after a reasonable observation window — usually 24 to 48 hours — expand the rollout to 25%, then 50%, then 100%. At any step, if you see a spike in errors or a drop in conversions, reduce the percentage back to 0% instantly. No deployment is required — the change takes effect within seconds across all running instances. Featureflip uses deterministic hashing, so the same users stay in the enabled group as you expand — you are not re-randomizing the population at each step. Once you reach 100% and the feature is stable, remove the flag from your code and archive it in Featureflip. Stale flags left in the codebase become invisible branches that confuse future developers and add unnecessary evaluation overhead. Treat flag cleanup as part of the definition of done for every feature.

What is a canary release in feature flags?

A canary release exposes a new feature to a small percentage of users first, so you can detect issues before a full rollout. The name comes from the mining practice of using canaries to detect toxic gases — your early adopters surface problems before they affect everyone. In Featureflip, you typically combine two layers: a targeting rule that serves the feature to internal employees or beta testers unconditionally (so your team always sees the new behavior), and a low percentage rollout on the fallthrough (say, 2-5% of general users). If the canary cohort shows elevated error rates or degraded metrics, you reduce the percentage to zero immediately. Once confident, you increase the percentage in stages. This pattern gives you real production signal without broad user impact, and it pairs naturally with Featureflip's per-environment configuration so canary traffic stays completely separate from your staging or QA environments.

Rollout Strategies & Percentage Rollouts

Rollout strategies determine how variations are distributed to users. Featureflip supports two strategies: fixed serving and percentage rollout. You can use them independently or combine them with targeting rules.

Fixed serving

With fixed serving, every user who matches a rule (or reaches the fallthrough) gets the same variation. There is no randomness or splitting.

This is the default strategy and the simplest to reason about:

Rule matches “enterprise” users — all enterprise users get true
Fallthrough — everyone else gets false

Fixed serving is the right choice when you want a binary decision: a group of users either gets the feature or they do not.

Percentage rollout

With percentage rollout, traffic is split across variations by percentage. For example:

true — 20% of users
false — 80% of users

This is useful for gradual rollouts (test with a small group before going wide) and A/B testing (compare two or more variations against each other).

You can apply a percentage rollout to the fallthrough or to individual targeting rules.

How percentage rollout works

Featureflip uses a deterministic hashing algorithm to assign users to buckets:

The user’s ID and the flag key are combined and hashed.
The hash produces a number between 0 and 100.
That number determines which variation the user receives based on the configured percentages.

Because the hash is deterministic, the same user always gets the same variation for the same flag. A user will not flip between variations on page refresh, across sessions, or between API calls. This consistency is important for a good user experience.

Different flags produce different hashes for the same user, so a user who is in the 20% group for one flag is not necessarily in the 20% group for another.

Gradual rollout pattern

The most common use of percentage rollout is a gradual feature release:

5% — Release to a small group. Monitor error rates and key metrics.
25% — Expand if metrics look healthy. Watch for edge cases.
50% — Half of users now have the feature. Continue monitoring.
100% — Full rollout. The feature is live for everyone.

At any step, if you see problems, reduce the percentage back down or set it to 0%. There is no deployment involved — the change takes effect within seconds.

Once a feature is at 100% and stable, remove the flag from your code and delete it from Featureflip. Stale flags add complexity.

Combining strategies

Targeting rules and rollout strategies work together. A common pattern:

Rule 1: email ends with "@yourcompany.com" — serve true (fixed). Your internal team always sees the feature for dogfooding.
Rule 2: Segment "Beta Users" — serve true (fixed). Beta testers always see the feature.
Fallthrough: 10% get true, 90% get false (percentage rollout). A small slice of general users also see the feature.

Rules are evaluated first, top to bottom. Users who match a rule get that rule’s variation and skip the fallthrough. Users who do not match any rule fall through to the percentage rollout.

This lets you guarantee access for specific groups while gradually exposing the feature to the broader user base.

Next steps

Targeting & Segments — attribute-based targeting and reusable segments
How to Set Up Targeting Rules — step-by-step guide to configuring rules and rollouts
How to Use Segments — create reusable user groups
Evaluation API — see how rollouts are resolved via the REST API