Feature Flags and Progressive Rollouts

Feature flags let you deploy code separately from enabling it for users, and disable a feature if problems appear.

Release to a smaller group first

A feature flag controls who can use a feature. You can begin with a small group, check what happens, and expand access as the results support it.

Feature flags let you enable or disable functionality for specific users without a new deployment. A progressive rollout can start with 1% of users and increase toward 100%, with checks before each expansion.

Risk when everyone receives a change at once

A release to all users exposes the whole audience to a bug in the affected feature. If that bug breaks checkout, restoring the service may require a rollback and coordinated engineering work. Limiting the initial audience gives the team a chance to detect a problem before expanding access.

A rollout plan should specify who receives the feature, what the team will monitor, and when to pause or disable it.

Separate deployment from release

Deploy the code with the feature disabled, then enable it for selected users. The deployment and the release can happen at different times.

A progressive rollout might move from 1% to 5% to 25% to 50% to 100%, with a review at each step. Disabling a flag can stop the affected code path, but it does not undo completed transactions or data changes. Test propagation time and rollback behavior.

What Are Feature Flags?

Conditional code that turns functionality on/off for different users. No new deployment needed.

Key principle: Deployment (code in production) ≠ Release (users see it).

Types of flags:

• Release flags: Temporary. De-risk new features. Remove after full release.
• Experiment flags: A/B tests. Different variants for different segments.
• Ops flags: Kill switches. Disable features causing load issues.
• Permission flags: Long-term. Control access by plan or role.

Progressive rollout stages

At each stage, check stability before increasing the share of users who can access the feature.

Illustrative stages:

Stage 1: Your Team First (0.1%)
   → Test with internal accounts and monitor shared systems.

Stage 2: Friendly Users (1%)
   → Use a beta group that understands the test and can report problems.

Stage 3: Small Sample (5%)
   → Check user impact and system health before expanding.

Stage 4: Confidence Check (25%)
   → Review results across the larger audience.

Stage 5: Majority Test (50%)
   → Continue checking for issues as traffic increases.

Stage 6: Full Launch (100%)
   → Continue monitoring after full release.

Choose the increments for your risk and traffic. At 5% exposure, 5 users in every 100 can encounter the feature. Check the rollout at each stage rather than assuming a fixed sequence of percentages is suitable for every release.

What flags let you control

• Disable a feature without rolling back the whole deployment.
• Limit initial exposure while checking for problems.
• Observe behavior with production users, traffic, and data.
• Deploy code before the product team is ready to release the feature.

Risk Assessment and Sample Size Planning

Before each rollout stage, work out how many users you need to detect issues. You're balancing the need for enough data against the risk of exposing more users to a problem.

Illustrative example: payment provider rollout

Let's apply this to something critical, changing payment providers:

• Feature: New payment provider integration
• Risk: High (touches checkout and revenue)
• User impact: All paying customers
• Rollback complexity: Medium (need both providers active)
• Monitoring: Strong (payment metrics tracked)

Your Rollout Strategy:

0.1% → Test with internal purchases only
1%   → Monitor for failed transactions
5%   → Check conversion rate impact
10%  → Watch for support tickets
25%  → Validate at scale
50%  → Continue checking edge cases and system health
100% → Full release; continue monitoring

Documented examples

Meta: Gatekeeper

Meta's engineering account describes keeping many changes behind Gatekeeper so code releases and feature releases can happen independently¹. This supports gradual exposure; it does not mean every feature follows one rollout sequence.

GitLab: flag controls

GitLab documents enabling and disabling flags through ChatOps, including rollout controls that block enabling flags during certain active incidents². These controls make the release process explicit; incident response still depends on the affected system and evidence.

Netflix: a different kind of test

Netflix's Chaos Monkey randomly terminates production instances to test resilience to instance failures³. It integrates with Spinnaker, but it is a resilience-testing tool, not a feature rollout strategy.

Progressive Rollout Strategies

These are illustrative sequences. Choose stages and observation periods based on risk, traffic, and the behavior you need to observe.

By Percentage

• Conservative: 0.1% → 1% → 5% → 10% → 25% → 50% → 100%
• Standard: 1% → 5% → 25% → 50% → 100%
• Aggressive: 5% → 25% → 100%

By Segment

• Internal → External: Employees → Beta → Power users → All
• Geographic: City → Country → Similar countries → Global
• Platform: Web → iOS → Android
• Plan tier: Enterprise → Pro → Free

By Risk Level

• Low (UI text): 10% → 50% → 100%
• Medium (new filter): 1% → 10% → 50% → 100%
• High (payments): 0.1% → 1% → 5% → 25% → 50% → 100%

Time-Based

• Hour 1: 1% traffic
• Hour 4: 5% if stable
• Day 2: 25% if clean
• Day 4: 50% if metrics good
• Week 2: 100% after validation

Monitoring During Rollout

Watch system health, business performance, and user experience as exposure increases.

1. System Health

Set thresholds using your baseline and reliability requirements. Illustrative thresholds include:

• Error rate: No more than a 0.1 percentage-point increase
• Page load time: No more than a 10% relative increase
• Success rate: Payment completion, form submission, etc.
• Server resources: CPU/Memory usage under a 20% relative increase

If errors jump from 0.1% to 1% at the 5% rollout stage, pause and investigate. The rollout percentage describes exposure, not the number of users affected; shared-system failures can also affect users outside that group.

2. Business Performance

These tell you if the feature helps or hurts business:

• Conversion rate: Are users still buying?
• Engagement: Time on site, pages viewed, features used
• Revenue per user: Immediate impact on money
• Feature adoption: Are users actually using the new feature?

A 5% conversion drop at 10% exposure warrants investigation. It does not establish a 5% revenue loss: revenue also depends on traffic, order value, and whether the measured difference persists.

3. User Experience

These tell you if users are struggling:

• Rage clicks: Clicking repeatedly on something broken
• Quick backs: Entering a page and immediately leaving
• Support tickets: Unusual spike in complaints
• Session abandonment: Higher drop rates than normal

If support tickets double at 1% exposure, check whether they concern the new feature. Ticket volume at full release cannot be inferred by multiplying the observed total by 100.

Set rollback triggers

Agree on the conditions for disabling a feature before launch. A predefined trigger gives the team a shared basis for deciding during an incident:

Illustrative triggers to adapt before launch:

• Critical: Error rate increases by 1 percentage point → Immediate rollback
• Severe: Conversion drops by 5% relative to baseline → Stop expansion, investigate
• Warning: Support tickets increase by 50% → Pause and monitor
• Caution: Load time increases by 20% → Slow expansion rate

Record who can pause or disable the feature and how the team will confirm recovery.

Feature Flags vs A/B Tests

A flag controls exposure. An A/B test uses a defined experiment design to compare outcomes; flags can support that assignment.

Feature Flags = Safety First

• Question: "Will this break anything?"
• Success: Nothing bad happens
• Duration: Days to weeks
• End result: Everyone gets the feature
• Example: Rolling out new payment provider to ensure it works

A/B Tests = Learning First

• Question: "Which version performs better?"
• Success: An interpretable result, which may be inconclusive
• Duration: Weeks to months
• End result: A decision based on results, uncertainty, and guardrails
• Example: Testing two checkout flows to see which converts better

Combine flags with experiments

Use a flag to release to a smaller segment, such as 10% of users. Once the feature is stable, you can run an A/B test within that segment. Check that the sample and design suit the question you want to answer.

Illustrative example:

1. Use feature flag to roll out new recommendation algorithm to 5% (safety)
2. Within that 5%, A/B test three ranking methods (learning)
3. Roll winning version to 100% (deployment)

Common Pitfalls

1. Flag Accumulation

Problem: Old flags clutter codebase. Fix: Give every flag an owner. Set removal dates for temporary flags and review dates for long-lived operational or permission flags.

2. Complex Dependencies

Problem: Flag A needs Flag B needs Flag C. Fix: Keep flags independent and single-purpose.

3. Poor Monitoring

Problem: Rolling out blind. Fix: Dashboard and alerts are prerequisites.

4. No Rollback Plan

Problem: Assuming you can "just turn it off." Fix: Test rollback in staging. Document process.

5. Inconsistent States

Problem: User sees feature, then doesn't. Fix: Ensure "stickiness" per user ID.

AI Prompts for Rollouts

Rollout Planning

Create rollout plan for [feature] considering:
- Feature complexity: [simple/medium/complex]
- User impact: [critical/nice-to-have]
- Rollback difficulty: [easy/medium/hard]
- Current monitoring: [metrics available]
Recommend stages, percentages, timeline.

Monitoring Setup

Generate monitoring metrics for [feature] rollout:
- Health metrics (errors, latency)
- Business metrics (conversion, engagement)
- User behavior signals
- Rollback thresholds
- Alert configurations
Use supplied baselines and service objectives to propose numeric thresholds. If those inputs are missing, ask for them and label any example threshold as an assumption.

Risk Assessment

Assess deployment risk for [feature]:
- Technical complexity
- User impact scope
- Revenue implications
- System dependencies
- Rollback complexity
Output risk level and strategy.

Implementation Best Practices

Flag Hygiene

1. Naming: feature_[team]_[name]_[date]
2. Documentation: Description, owner, ticket, removal date
3. Audits: Review quarterly, remove stale flags
4. Maximum lifetime: Few months for release flags
5. Code reviews: Include removal plan

Rollout Checklist

• Risk assessment complete
• Success/failure metrics defined
• Rollback plan documented
• Monitoring dashboard created
• Alerts configured
• Communication plan ready
• Stages and percentages decided
• Timeline established

Team Responsibilities

• PM: Strategy, metrics, go/no-go decisions
• Engineering: Implementation, monitoring, execution
• QA: Test on/off states, validate rollback
• DevOps: System health, infrastructure issues
• Support: Watch ticket volume

Additional rollout techniques

Once basic rollouts feel routine, these techniques add more control:

Ring deployments

Expand through defined groups, for example:

• Ring 0: Your team
• Ring 1: Early adopters
• Ring 2: Pilot users
• Ring 3: Production canaries
• Ring 4: Broad deployment

Choose groups that cover relevant environments and usage patterns.

Blue-green deployment with flags

Deploy to a parallel environment and use routing controls to switch traffic. Feature flags can separately control behavior within either environment. Switching back does not undo data changes; test compatibility and recovery.

Canary Analysis

Statistical comparison of canary (new) vs control (old) groups. Promote or roll back according to predefined statistical and operational criteria.

Action Items by Experience Level

Never Used Feature Flags? Start Here:

Today (5 min): List your next 3 features. Label each as low/medium/high risk. This Week (30 min): Check how your application and deployment tools support feature flags. Next Feature (2 hours): Plan a manual "soft launch" to 10 customers first.

Have Basic Experience? Next Steps:

This Sprint: Document your first formal rollout plan with stages and metrics. This Quarter: Implement one feature flag using your existing tools.

Next steps

This month: Set up automated monitoring and rollback triggers. Next quarter: Implement canary analysis with statistical validation.

Next Steps

Tools to plan your next rollout:

1. Run experiments with A/B Test Calculator
2. Calculate sample needs with Sample Size Calculator

Sources