FeatBit

Automatic Rollback

An expansion fails. Return to the last healthy stage.

When a rollout from 10% to 20% causes a regression, restore the previous 10% through the REST API, FeatBit CLI, or FeatBit MCP. Use a Trigger to switch OFF when the release needs the stable fallback.

Try FeatBit See the solution
HEALTH SIGNALLAST SAFE20% → 10%

A practical walkthrough with checkout-experience

The story · A healthy 10% canary. A failing 20% expansion.

The first 10% was healthy. Errors appear after the release reaches 20%.

The checkout team records each rollout stage before expanding. When payment failures rise at 20%, its monitoring workflow can restore the previous 10% through the REST API, CLI, or MCP. A Trigger can switch the flag OFF when the recovery policy requires the stable fallback.

Illustrative scenario · Real product configuration

Inside FeatBit · 4 steps

Switch OFF, or return to the last healthy stage.

Your monitoring workflow can invoke an OFF trigger or restore a saved rollout through the REST API, FeatBit CLI, or FeatBit MCP. Choose the recovery target before expanding.

  1. 01Step 01 / 04

    Prepare both recovery targets.

    Test Existing checkout as the OFF variation. Before expanding a healthy canary from 10% to 20%, record the 10% New checkout / 90% Existing checkout configuration, including variation IDs, order, and dispatch key.

    Flag
    checkout-experience
    Last healthy stage
    10% new / 90% existing
    OFF variation
    Existing checkout

    The alert response can restore the previous stage or switch the feature OFF, according to the release policy.

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

    OFF action

    Tested fallback

    Prepare the action’s application behavior

  2. 02Step 02 / 04

    Use a Trigger to switch the feature OFF.

    For full containment, open Triggers and prepare a General trigger with the Turn OFF action. Configure your monitoring workflow to invoke it when the release policy calls for the stable fallback.

    Type
    General
    Action
    Turn OFF

    This screenshot shows an unsubmitted setup form; no trigger URL was created for the demo.

    Inside FeatBitLive app · Demo
    Swipe to inspect
    Triggers → Create trigger · Setup example

    Payment health alert

    FeatBit OFF trigger

    Your alerting service invokes the action

  3. 03Step 03 / 04

    Roll back the last expansion: 20% → 10%.

    If the regression appeared after expanding to 20%, your workflow can restore the recorded 10% stage through the REST API, FeatBit CLI, or FeatBit MCP. Reapply the saved default rollout while keeping the flag ON and the same variation IDs, order, and dispatch key.

    Before recovery
    20% new / 80% existing
    Restore previous stage
    10% new / 90% existing
    Flag status
    ON

    Read the configuration back to confirm the restored allocation. This example rolls back the last expansion; the earlier 10% must be a validated recovery target.

    Restore the last healthy rolloutCall examples · 20% → 10%
    rollout='[
  {"variationId":"<new-checkout-id>","percentage":10},
  {"variationId":"<existing-checkout-id>","percentage":90}
]'

featbit flag set-rollout \
  --env-id "<env-id>" \
  --flag-key checkout-experience \
  --dispatch-key keyId \
  --rollout "$rollout"

    Replace the placeholders with the saved 10% stage’s environment and variation IDs. Preserve its variation order and dispatch key. These examples restore the default rollout; check any targeting rules separately.

    REST APICLI commandMCP tools

    20% · Alert fires

    10% · Previous stage

    10% → 20% → 10% · Restore the recorded rollout with the flag ON

  4. 04Step 04 / 04

    Rehearse the action and verify recovery.

    Connect your payment-failure alert to the chosen action. For the Trigger path, create the trigger and store its URL in the monitoring tool’s secret storage. Test the alert, read back the flag status and allocation, and confirm recovery in application telemetry.

    Recovery target
    Previous 10% stage or OFF fallback
    After the change
    Verify payment health

    Review later scheduled changes before resuming so an expansion cannot reopen the failing release.

    Inside FeatBitLive app · Demo
    Swipe to inspect
    Trigger description → Intended recovery

    Prepared recovery action

    Recovery verified

    Test the complete alert → flag → application loop

The next decision

Verify recovery before the next expansion.

Confirm that the chosen action restored the recorded 10% stage or switched the flag OFF. Check application health and review pending scheduled changes before resuming the release.

Build your own release in FeatBit

Record the recovery target before expanding

Save the environment, variation IDs, order, and dispatch key of the healthy stage. Your monitoring workflow selects the prepared recovery action. Read back the result and check application health before expanding again.

From idea to implementation

Build your release path.

Create and invoke flag triggersRestore a default rollout with the REST APISet rollout percentages with FeatBit CLIOperate feature flags through FeatBit MCPManage scheduled flag changesDesign a release decision framework

Keep the release moving.

All solutions

Instant Feature Rollback

When a new checkout or exporter breaks, restore the working path through a flag change while your team prepares the fix.

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.

Scheduled Releases

Deploy AI-assisted changes early, then schedule a reviewed pilot for a time when monitoring and recovery owners are ready.