Do users lose a feature if I lower the rollout?
Last updated:
Yes. Buckets are fixed per user, so lowering a rollout from 50% to 20% keeps everyone in buckets 0 through 19 and removes everyone from 20 through 49. It is deterministic, not a reshuffle, which is why raising the percentage again restores exactly the same people. Users who lose access see the feature disappear mid-session unless you evaluate once per session and cache the result.
Yes. The useful part is that you can say in advance which users.
A user’s bucket is a fixed number from 0 to 99 derived from a per-flag salt and their user key. It does not change when you edit the rollout. What changes is where the boundary sits. At 50% the enabled band covers buckets 0 through 49, and dropping to 20% narrows it to 0 through 19. Everyone from 20 to 49 loses the feature, and everyone below 20 never notices.
Why the ladder is safe
Because the assignment is stable, the ladder up and back down is symmetric.
Going 5% to 25% to 50% only ever adds people. Nobody who had the feature at 5% loses it at 25%, so your early cohort keeps a consistent experience through the whole rollout and any metrics you gather on them stay comparable. Roll back to 5% and you get the same users you started with, down to the individual.
That symmetry is what makes a percentage gate safe to reach for during an incident.
What users actually see
The change reaches connected SDKs within seconds. That speed is the whole point of a percentage gate, and it also means a user can lose a feature while they are looking straight at it, which is the one part of this worth designing around.
// Evaluate once at session start, then reuse the answerconst canSeeNewCheckout = client.boolVariation('new-checkout', ctx, false);For anything a user is midway through, evaluate at a natural boundary and hold the result for that session instead of re-evaluating on every render. A checkout that vanishes between steps will generate a support ticket. One that survives until the next page load usually will not. In a genuine emergency the immediate cut is of course exactly what you want.
One thing that does re-bucket
Changing the rollout percentage is safe. Changing which attribute the rollout buckets by replaces one of the hash inputs, so it reassigns everybody at once. Treat that as starting a new rollout.
Deleting and recreating a flag has the same effect, since a fresh flag gets a fresh salt.
Bucket stability and the rollout ladder are covered in Rollout strategies, with the operational sequence in Progressive rollouts.
Related questions
Why doesn't my rollout hit the percentage I set?
A 20% rollout rarely serves exactly 20% of traffic. Bucketing is deterministic per user, so small populations skew and anonymous traffic behaves differently.
Does changing a targeting rule re-bucket users?
Editing rules, weights or conditions leaves every bucket where it was. Only two changes reassign users, and both are easy to make by accident.
Why do two users get different variations?
That is what a percentage rollout does. Bucketing hashes the user ID with the flag key, so the split is per user and per flag, and never lines up across flags.
Still stuck?
The docs cover every SDK, and the free Solo plan is enough to reproduce most of these locally.