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 answer
const 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.

Still stuck?

The docs cover every SDK, and the free Solo plan is enough to reproduce most of these locally.