Rollouts

Rollouts let you release a feature to a fraction of your users — say 5% — and increase that percentage over time. This reduces blast radius: if something goes wrong, only a small portion of users is affected.

How percentage rollouts work

Every flag has a rollout percentage (0–100). When a flag is evaluated:

1. The SDK computes a hash: hash(userId + flagKey) % 100
2. If the result is less than the rollout percentage, the user gets the on variation
3. Otherwise, the user gets the off variation (typically false or the second variation)

This bucketing is deterministic — the same user always gets the same result for the same flag, regardless of which SDK or server handles the request. No database or state is required.

Deterministic rollouts require a userId in the context. Without one, the hash is not stable and results may vary between evaluations.

Setting a rollout percentage

In the Flagpool dashboard:

1. Navigate to your flag
2. Select the environment (e.g., Production)
3. Set the Rollout Percentage slider (0–100%)
4. Save

The change propagates to all SDKs via the CDN, typically within seconds.

Rollout strategies

Linear rollout

Increase the percentage at regular intervals:

Day 1:   1%    → monitor metrics
Day 2:   5%    → check error rates
Day 3:   25%   → validate at scale
Day 5:   50%   → broad validation
Day 7:   100%  → full launch

Canary rollout

Start very small to catch issues early:

Hour 0:  0.1%  → smoke test
Hour 4:  1%    → basic validation
Day 1:   10%   → broader test
Day 3:   50%   → scale test
Day 5:   100%  → full launch

Ring deployment

Roll out in concentric rings, starting with internal users:

Ring 0:  Internal team     → use targeting rules to match @yourcompany.com
Ring 1:  Beta users        → use a target list of opt-in users
Ring 2:  Pro customers     → target plan eq "pro"
Ring 3:  Everyone          → set rollout to 100%

Combining rollouts with targeting

Targeting rules take precedence over rollout percentage:

1. Rules are checked first — if a rule matches, its variation is returned immediately
2. Rollout applies to the rest — users who don't match any rule are subject to the percentage

Example: Always show the feature to enterprise users, but only roll out to 10% of everyone else:

Configuration	Value
Rule: plan eq "enterprise"	→ variation 0 (enabled)
Rollout percentage	10%
Default variation	0 (enabled, for the 10% in rollout)
Off variation	1 (disabled, for the 90% outside rollout)

Enterprise users always get the feature. Of the remaining users, 10% are bucketed into the rollout and see the feature; 90% see the old behavior.

Instant rollback

If you detect an issue after rolling out:

1. Set the rollout percentage to 0%
2. Or toggle the flag off entirely

The change propagates globally in under 50ms via the CDN. SDKs pick it up on their next poll cycle (default: 30 seconds, or instantly with streaming enabled).

Monitoring rollouts

Watch these signals as you increase rollout percentage:

• Error rates — are errors increasing?
• Latency — is the new code path slower?
• User feedback — any support tickets related to the feature?
• Business metrics — are conversion rates, revenue, or engagement affected?

If any signal looks bad, roll back immediately and investigate.

Next steps

• Targeting — combine rollouts with targeting rules
• Contexts — provide userId for deterministic bucketing
• Kill Switches — emergency rollback patterns