Tutorial December 3, 2025 6 min read

The Complete Guide to Progressive Rollouts

Shipping to 100% of users on day one is risky. Progressive rollouts let you test in production with real users while limiting blast radius. Here's how to do it right.

What is a Progressive Rollout?

A progressive rollout (also called a gradual rollout or percentage deployment) releases a feature to a small percentage of users first, then increases that percentage over time.

Typical Rollout Schedule
Day 1
1%
Day 2
10%
Day 3
25%
Day 5
50%
Day 7
100%

How Percentage Rollouts Work

The feature flag system uses a hash of the user ID to determine if a user is in the rollout. This ensures:

  • Consistency - The same user always gets the same experience
  • Stickiness - Once enabled for a user, it stays enabled
  • Determinism - No database lookups needed per request
// Simplified percentage check
hash = murmurhash(userId + flagKey)
percentage = hash % 100
isEnabled = percentage < rolloutPercentage

Before You Roll Out

1. Define Success Metrics

Before shipping, know what you're measuring:

  • Error rates - Is the new code breaking things?
  • Latency - Is performance acceptable?
  • Business metrics - Conversion, engagement, revenue

2. Set Rollback Criteria

Define when you'll automatically stop the rollout:

  • Error rate > 1% (baseline: 0.1%)
  • P99 latency > 500ms (baseline: 200ms)
  • Conversion rate drops > 5%

3. Prepare Your Rollback

The rollback should be one click. In Flagit, you just toggle the flag off or set the percentage to 0%. The change propagates instantly via SSE.

Rollout Strategies

Strategy 1: Linear Increase

Simple and predictable. Increase by a fixed amount each day.

1% → 5% → 10% → 25% → 50% → 100%

Best for: Low-risk features, UI changes, non-critical paths.

Strategy 2: Ring Deployment

Start with specific user groups before percentage rollout.

Internal → Beta Users → 10% → 50% → 100%

Best for: Major features, breaking changes, high-risk code.

Strategy 3: Geographic Rollout

Roll out to one region at a time.

Australia → EU → US East → US West → Global

Best for: Infrastructure changes, latency-sensitive features.

Example: New Checkout Flow

Let's walk through a real example - rolling out a new checkout experience.

1 Internal Testing

Enable for internal team via email ends with @company.com rule.

2 Beta Users (1%)

Enable 1% rollout. Monitor error rates, checkout completion rate.

3 Expand to 10%

After 24 hours with no issues, increase to 10%. Watch for edge cases.

4 50% Rollout

At 50%, you have statistical significance for A/B comparison. Compare metrics.

5 Full Rollout

Enable for 100%. Schedule flag cleanup in 2 weeks.

When Things Go Wrong

Rollbacks happen. Here's how to handle them:

  1. Don't panic - The feature flag exists exactly for this moment
  2. Kill the rollout - Set percentage to 0% immediately
  3. Assess impact - How many users were affected?
  4. Investigate - What went wrong? Fix and try again

Pro Tip

Keep the "old" code path working until you're at 100% and have removed the flag. Never delete the fallback while the flag is still in use.

Summary

Progressive rollouts are your safety net. They let you:

  • Test in production with real users
  • Catch issues before they affect everyone
  • Roll back instantly without a deploy
  • Compare metrics between old and new experiences

Start small. Monitor closely. Expand with confidence.

Back to Blog