What is a percentage rollout?

A percentage rollout serves a new variation to a fixed share of your users and lets you raise that share over time. Instead of turning a feature on for everyone at once, you enable it for 1%, watch your metrics, then step up to 5%, 25%, and eventually 100%. With Featureflip the percentage is a value in the flag configuration, so changing it is a dashboard action that propagates to the SDKs in seconds rather than a code change and redeploy.

Do the same users stay in the rollout as I increase the percentage?

Yes. Featureflip assigns buckets by hashing the user identifier together with the flag key, which is deterministic: the same user always maps to the same bucket for that flag. When you move from 5% to 25% you are adding users to the enabled cohort, not re-randomising the population, so the original 5% keep the feature and never flip back. This behaviour is called sticky bucketing, and it is what makes a rollout safe to ramp and safe to compose with an experiment.

Can I change the rollout percentage without redeploying?

Yes, and that is the point of gating a rollout on a flag rather than a config file. Deploy the code once with the flag at 0%, then adjust the percentage from the Featureflip dashboard. The new value streams to every connected SDK over Server-Sent Events and takes effect on the next evaluation, usually within a second or two. Rolling back is the same operation in reverse: set the percentage to zero and the new path stops running fleet-wide.

Can I roll out more than two variations by percentage?

Yes. A percentage rollout is not restricted to on and off. You can split traffic across three or more variations with weights you set, such as 80% control, 10% variant A, and 10% variant B, and the weights sum to 100%. The same deterministic hashing pins each user to their assigned variation, so a user who lands in variant A stays in variant A as you adjust the split. This is a weighted, or multivariate, rollout.

How is a percentage rollout different from a targeting rule?

A targeting rule serves a variation to users who match an attribute you know about, for example everyone whose plan is Enterprise or whose email ends in your company domain. A percentage rollout splits the users a rule does not single out, using the deterministic hash rather than any attribute. The two compose: rules are evaluated first, and the percentage applies to whoever falls through. A common setup gives internal staff unconditional access with a rule while everyone else follows the percentage ladder.

Does a percentage rollout stay consistent across servers?

Yes. Because bucketing is a pure function of the user identifier and the flag key, every SDK instance computes the same assignment for the same user without coordinating. You do not need sticky sessions, a shared cache, or a central service to keep a user on one side of the split. Ten servers behind a load balancer will all agree on whether a given user is in the rollout, which is what keeps the experience consistent as requests fan out across your fleet.

Product feature

Percentage rollouts

Serve a feature to 1% of users, then move the number up when the metrics hold. The percentage is a setting, not a deploy, and the same users stay in as you climb.

Last updated: July 2, 2026

A percentage rollout serves a new variation to a fixed share of your users, and lets you raise that share on a slider as the release proves out. In Featureflip the percentage is a value in the flag config: change it in the dashboard and the SDKs receive it over a streaming connection within seconds, no redeploy involved. Assignment is deterministic, so a user who is in the rollout at 5% is still in it at 50%. The result is a release you can ramp gradually, hold at any level, and reverse in a single click.

Get started free Read the rollout strategy docs

How Featureflip's percentage rollouts work

The mechanics that turn a percentage into a safe, reversible dial instead of a coin flip at every step.

Deterministic sticky bucketing

Featureflip hashes the user identifier together with the flag key to assign each user a stable bucket. The same user always lands in the same bucket for the same flag, so raising the percentage adds new users to the enabled cohort without re-rolling the ones already in it. Nobody flips back to the old experience mid-ramp.

Change the percentage without a redeploy

The percentage lives in the flag configuration, not in your code. Move the number in the dashboard and the SDKs pick it up on the spot. Your application binary never changes between 1% and 100%, so the deploy and the release are two separate, independently reversible events.

Sub-millisecond local evaluation

Each SDK holds the flag config in memory and computes the bucket locally. There is no network round trip on the request path and no shared flag service your hot path depends on to stay alive. Putting a percentage-gated flag in a tight loop adds no measurable latency.

Live updates over Server-Sent Events

When you change a percentage, Featureflip streams the new config to every connected SDK over its open SSE connection. Propagation is typically a second or two, fleet-wide. That is what makes ramping in tenths of a percent, or cutting straight back to zero during an incident, a practical operation rather than a redeploy cycle.

Per-environment control

A flag carries an independent percentage in every environment. Hold production at 5% while staging runs at 100%, promote the number when the signal is clean, and never leak a staging ramp into production. Each environment is its own dial.

Multivariate weighted rollouts

A rollout is not limited to on and off. Split traffic across three or more variations with the weights you choose, for example 80% control, 10% variant A, 10% variant B. The same deterministic hashing keeps each user pinned to their assigned variation as you adjust the weights.

For the exact bucketing algorithm and how the fallthrough interacts with rules, see the rollout strategies documentation. For the term itself, the percentage rollout glossary entry has the short version.

Running a rollout, step by step

The same four moves work for a copy tweak or a rewrite of your checkout flow. Featureflip moves the exposure; your monitoring decides the pace.

1
Deploy with the flag at 0%
Ship the new code path behind a flag set to zero percent. It runs on every server but executes for nobody. The deploy is a non-event: the binary is in place and no user is exposed yet.
2
Raise the percentage in the dashboard
Move the rollout to 1%, then 5%, then higher. Each change streams to the SDKs in seconds. A stable slice of your users starts hitting the new path, and the same slice stays enabled as you climb.
3
Watch your own metrics between steps
Featureflip changes the exposure; your dashboards tell you whether to keep going. Compare error rate and latency on the new path against the control, and only advance when the current tier looks healthy.
4
Go to 100%, or cut back to 0%
When the ramp is clean, set it to 100% and the new path becomes the only path. If a metric turns red at any step, set the percentage back to zero and the new code stops executing on the next evaluation. Rollback is a config change, not a revert.

Prefer a worked example with a suggested 1% to 100% ladder and the metrics to watch at each tier? The progressive rollouts use case walks through one, and pairs the percentage with an instant kill switch for the moment a metric turns red.

What it looks like in your app

Your code does not know it is in a rollout. It asks the SDK for the flag's value, passing the user so the bucket is stable, and branches on the answer:

if (client.evaluate('checkout-v2', user, false)) {
  return renderNewCheckout(user);
}
return renderLegacyCheckout(user);

At 0% every call returns false. At 5% a stable 5% of users get true. The code is identical at every step of the ramp. A weighted rollout is the same call with a string default, returning whichever variation the user is bucketed into:

// weights set in the dashboard: 80% "control", 10% "compact", 10% "spacious"
const layout = client.evaluate('dashboard-layout', user, 'control');
render(layout);

The surface is the same in every language Featureflip supports. Pick your platform from the SDK overview, and see setting up targeting rules for stacking a rule above the percentage.