FeatBit

Scheduled Releases

Code is ready. Launch when your team is, too.

The code is deployed ahead of the launch window. Prepare a 10% true / 90% false rollout and schedule its first stage for a time when monitoring, support, and the recovery owner are ready.

Try FeatBit See the solution
zz

A practical walkthrough with scheduled-rollout

The story · A morning launch with an owner online

The code is ready. The first 10% goes live when support is ready.

The implementation finishes ahead of the launch window. The team prepares a 10% true / 90% false rollout, schedules its first stage for a staffed window, and checks service health before expanding.

Illustrative scenario · Real product configuration

Inside FeatBit · 4 steps

Configure the rollout. Choose when it goes live.

Define the feature flag’s rollout strategy in Targeting first, then schedule when that strategy should take effect.

  1. 01Step 01 / 04

    Start with 10% true and 90% false.

    Open scheduled-rollout → Targeting and choose Rollout percentage for the default ON rule. Allocate 10% to True and 90% to False, with keyId as the dispatch property. Apply the allocation to the pending change, then choose Schedule changes from the Review & save menu.

    True · new feature
    10%
    False · existing experience
    90%
    Dispatch by
    keyId

    The first scheduled stage exposes the feature to 10% of users. Keep False as the OFF variation and review health before later expansion.

    Inside FeatBitLive app · Demo
    Swipe to inspect
    Targeting → Percentage rollout · True 10% / False 90%

    100% of traffic

    10% true · 90% false

    Set the first stage before choosing its launch time

  2. 02Step 02 / 04

    Choose the date, time, and time zone.

    Name the first stage Start rollout at 10% and select a window when support and the recovery owner are available. Check the time zone displayed by the product before scheduling.

    Demo window
    2 Nov 2026 · 10:00
    Displayed time zone
    Asia/Shanghai

    The setup shown here was canceled after capture; it does not create a future release.

    Inside FeatBitLive app · Demo
    Swipe to inspect
    Schedule targeting changes → Launch window

    Reviewed change

    Staffed launch window

    Confirm the displayed time zone

  3. 03Step 03 / 04

    Leave the launch intent with the change.

    Record that the release starts at True 10% / False 90% while support and the recovery owner are online. Complete any required approval. After execution, verify the allocation and service health before expanding.

    Initial allocation
    True 10% / False 90%
    Before expansion
    Verify allocation and service health

    The clock controls timing; the release owner still checks whether the change is healthy.

    Inside FeatBitLive app · Demo
    Swipe to inspect
    Schedule targeting changes → Reason and approval

    10% canary starts

    Owner verifies health

    Execution and release health are separate checks

  4. 04Step 04 / 04

    Review every pending stage before it runs.

    Open Pending changes to see the queued work and its status. The game runner example here contains four planned rollout changes. Check each execution time and time zone: the titles alone do not determine their order.

    Panel
    4 pending changes
    Status shown
    Pending execution
    Time zone
    Asia/Shanghai

    A queued change has not executed yet. Review later expansions whenever a pilot is paused or rolled back.

    Inside FeatBitProduct preview
    Swipe to inspect
    game runner → Pending changes

    Queued release stages

    Review timing and status

    Check the actual dates before the next expansion

The next decision

A successful scheduled change still needs a release review.

Verify the change actually ran and the intended users receive it. Use production health to decide expansion, and remove pending expansions if the pilot needs to stop.

Build your own release in FeatBit

A clock controls timing; health controls expansion

A scheduled targeting change runs at a planned time. Connect monitoring and a recovery process separately, and review later scheduled steps if an earlier stage needs to stop.

From idea to implementation

Build your release path.

Schedule and review flag changesConnect alert-driven rollbackPlan the full release workflow

Keep the release moving.

All solutions

Progressive Rollouts

Start an AI-assisted checkout with a small canary. Review errors and completion before more users receive the candidate.

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%.

Segment-Based Releases

Try a search rewrite with an opt-in beta or a regional pilot. Use the same limited audience across related feature flags.