Progressive Rollouts

This guide walks you through running a progressive rollout from start to finish — from initial canary release to full launch. For the underlying concepts, see Rollouts.

Before you start

Make sure you have:

1. A feature flag created in the Flagpool dashboard
2. The SDK integrated in your application with a userId in the context (required for deterministic bucketing)
3. Monitoring in place for the metrics you care about (error rates, latency, business KPIs)

Step 1: Start with internal users

Before any percentage rollout, validate with your own team using a targeting rule:

Rule: IF email CONTAINS "@yourcompany.com" → enabled
Default: disabled
Rollout: 0%

This lets your team verify the feature in production with real data before any external users see it.

Step 2: Canary release (0.1–1%)

Once internal testing looks good, start the rollout small:

1. Navigate to your flag in the dashboard
2. Select the Production environment
3. Set the rollout percentage to 1%
4. Save

Timeline:
  Hour 0:  Set rollout to 1%
  Hour 1:  Check error rates — any increase?
  Hour 4:  Check latency — is the new code path slower?
  Hour 8:  Check business metrics — conversion, revenue

At 1%, if something goes wrong, only a tiny fraction of users is affected.

Step 3: Gradual increase

If the canary looks healthy, increase the percentage in stages:

Day 1:    1%   → smoke test
Day 2:    5%   → basic validation
Day 3:   25%   → scale test
Day 5:   50%   → broad validation
Day 7:  100%   → full launch

What to watch at each stage:

Percentage	Focus
1%	Errors, crashes, basic functionality
5%	Performance under light load
25%	Database and API load patterns
50%	Full-scale behavior, edge cases
100%	Confirm stability, then clean up the flag

Step 4: Full launch

Once you're at 100% and confident:

1. Set the rollout to 100% and remove any targeting rules
2. Monitor for another day or two
3. Remove the flag from your code (it's now the default behavior)
4. Delete the flag from the dashboard

Tip: Use Flagpool's analytics to verify the flag is actually being evaluated. If evaluation counts are zero after launch, the code path may not be reachable.

Emergency rollback

If you detect an issue at any point:

1. Set the rollout percentage to 0% — or toggle the flag off entirely
2. The change propagates globally in under 50ms via the CDN
3. SDKs pick up the change on their next poll cycle (default: 30 seconds)

Total rollback time: ~1-2 minutes vs 10+ minutes for a code redeploy.

Combining rollouts with targeting

Targeting rules take precedence over the rollout percentage. This lets you create powerful combinations:

Example: Always enable for enterprise customers, rollout to 10% of everyone else:

Configuration	Value
Rule: plan eq "enterprise"	→ enabled
Rollout percentage	10%
Default (for users in the 10%)	enabled
Off (for users outside the 10%)	disabled

Enterprise users always see the feature. Of the remaining users, 10% are bucketed into the rollout.

Rollout patterns

Linear rollout

Best for low-risk features where you want steady progress:

Day 1:   1%  →  Day 2:   5%  →  Day 3:  25%  →  Day 5:  50%  →  Day 7:  100%

Canary rollout

Best for high-risk changes where you need extended validation:

Hour 0:  0.1%  →  Hour 4:  1%  →  Day 1:  10%  →  Day 3:  50%  →  Day 5:  100%

Ring deployment

Best for organizations with clear user tiers:

Ring 0:  Internal team       (targeting rule: email contains @yourcompany.com)
Ring 1:  Beta users          (target list: beta-testers)
Ring 2:  Pro customers       (targeting rule: plan eq "pro")
Ring 3:  Everyone            (rollout: 100%)

Checklist

Before starting a rollout:

• Feature flag created and tested in a non-production environment
• userId is set in the SDK context for deterministic bucketing
• Monitoring dashboards are ready (error rates, latency, business metrics)
• Team knows the rollback procedure (set to 0% or toggle off)
• Rollout schedule is agreed upon (how fast to increase)

Next steps

• Rollouts — the underlying concepts and deterministic hashing
• Targeting — combine rollouts with targeting rules
• Kill Switches — emergency rollback patterns
• A/B Testing — use rollouts for controlled experiments