Percentage Rollouts

Percentage Rollouts

A percentage rollout rule lets you release a flag to a fraction of your users. Instead of turning a flag on for everyone at once, you can start at 10%, verify your system is healthy, then ramp to 50% and finally 100%.

Creating a rollout rule in GrowthBook

1. On the Feature detail page, click Add Rule.
2. Choose Rollout (percentage) as the rule type.
3. Set the Coverage percentage (e.g. 10).
4. Set the Hash Attribute — this is the user attribute whose value is hashed to decide bucket assignment (usually id).
5. Optionally add Targeting Conditions to restrict the rollout to a subset of users.
6. Click Save Rule.

How bucketing keeps users consistent

GrowthBook hashes the user’s hash attribute value (e.g. their id) with the feature key to produce a number between 0 and 1. If that number is below the coverage percentage, the rule matches. Because the hash is deterministic, the same user always lands in the same bucket — raising the coverage from 10% to 50% only adds new users; it never flips existing users.

Ramping a rollout

A typical ramp schedule: start at 10% for 24 hours, watch your error rates and metrics. If healthy, move to 50% for another 24 hours. Then roll out to 100% and remove the flag.

gb.setAttributes({ id: 'user-123' });
if (gb.isOn('new-dashboard')) {
  // user-123 is consistently in the 10% bucket
}

gb.setAttributes({ id: 'user-123' });
if (gb.isOn('new-dashboard')) {
  // user is deterministically in or out based on id hash
}

Copy rollout snippet ⧉

🧪 Percentage rollouts hash the user id for stable bucketing

Raising coverage from 10% to 50% adds new users to the rollout — it does not reassign existing users. A user who saw the new feature at 10% will continue to see it at 50% and 100%.

Rollout Strategy Comparison

Strategy	Risk	Speed
Big Bang Release	High	Fast
Canary Release	Medium	Medium
Progressive Rollout	Low	Slow
Feature Flag	Very low	Adjustable as needed

Trade-offs

Option	Benefit	Cost
Slow rollout (staged percentages)	Safer, catches problems before they hit many users	Takes longer to reach 100%
Fast rollout	You see results in hand sooner	Larger blast radius if something breaks

Common mistakes

• Rolling out to 100% immediately without going through small percentage stages first
• Not monitoring metrics during each rollout stage
• Increasing the percentage too quickly without waiting long enough to see the previous stage’s results

💡 Real-world example

Progressive rollout (e.g. 1% → 5% → 25% → 100%) is a common industry pattern for shipping large features, so a bug’s blast radius is limited before it reaches everyone.

What is the hash attribute used for in a percentage rollout?

It sets the maximum number of users allowed in the rollout Its value is hashed with the feature key to determine which bucket a user falls into It defines the targeting condition for the rollout rule It controls the ramp schedule timing

What happens to existing users who are already in a rollout when you raise coverage from 10% to 50%?

They are randomly reassigned to new buckets They are removed from the rollout and must re-qualify They continue to see the feature — only new users are added They see the flag as off until the ramp completes

What is a typical first coverage percentage for a cautious rollout?

1% 10% 50% 75%

Submit

Mark as complete