FeatBit

Progressive Rollouts

Give your next release a smaller first step.

The new checkout passed staging. Real payment methods and devices still need a say. Start with a small canary, watch what happens, and make each wider audience a deliberate decision.

Try FeatBit See the solution
5%25%100%

A practical walkthrough with checkout-experience

The story · A checkout canary before the full launch

The new checkout passed staging. Production gets a smaller first step.

The team has simplified checkout, but staging cannot represent every payment method and customer device. A missed edge case should be discovered while most people still have the working checkout.

Illustrative scenario · Real product configuration

Inside FeatBit · 3 steps

Start small, review, then earn the next stage.

Keep both checkout paths deployed and make each increase in exposure a separate decision.

  1. 01Step 01 / 03

    Choose the recovery path first.

    Set Existing checkout as the OFF variation before exposing the candidate. The application must still implement that tested path.

    Flag
    checkout-experience
    Flag OFF
    Existing checkout

    The rollout has a working path to return to if the candidate fails.

    Inside FeatBitLive app · Demo
    Swipe to inspect
    Targeting → Flag OFF variation

    Candidate has a bug

    Existing checkout

    Prepare recovery before exposure

  2. 02Step 02 / 03

    Allocate a 5% canary.

    Choose percentage rollout and assign 5% to New checkout and 95% to Existing checkout. Dispatch by a stable identity so the rollout unit stays consistent.

    New / existing
    5% / 95%
    Dispatch by
    keyId

    Most users retain the stable path while a small audience validates the candidate.

    Inside FeatBitLive app · Demo
    Swipe to inspect
    Targeting → Percentage rollout

    5% candidate

    95% stay stable

    An example canary allocation

  3. 03Step 03 / 03

    Review the recorded change before expanding.

    Save the allocation with a clear change comment. Compare payment failures, latency, and completion in your telemetry before moving to 25% or 100%.

    Next stage
    After a health review
    If a regression appears
    Hold or reduce exposure

    The next percentage follows evidence; a saved allocation does not certify release health.

    Inside FeatBitLive app · Demo
    Swipe to inspect
    History → Targeting change

    Canary evidence

    Hold or expand

    Review before the next percentage change

The next decision

Increase exposure when the evidence supports it.

Compare the candidate's failures and completion with the stable path, using enough traffic for a useful review. Stop expansion while a regression remains unexplained.

Build your own release in FeatBit

Match the rollout unit to the experience

For collaborative software, consider dispatching by a shared account attribute so teammates receive the same variation. Keep identifiers stable and separate a canary health check from a controlled A/B experiment.

From idea to implementation

Build your release path.

Configure percentage rolloutsSchedule rollout stagesUnderstand progressive rollout patterns

Keep the release moving.

All solutions

Feature Impact Monitoring

Explore the Release Health design: connect metric sources, define guard conditions, send webhook alerts on threshold breaches, and investigate with release context.

Automatic Rollback

Connect health alerts to an OFF trigger or restore a previous rollout through the REST API, FeatBit CLI, or MCP, such as returning from 20% to 10%.

Feature Experimentation

Compare two experiences with a stable feature flag split. Follow Exposure and Measuring through the primary metric, posterior distribution, and guardrails.