Skip to main content
A rollout is a gradual increase in traffic for a new parameter value. Use rollouts when you want to ship a change carefully: start with a small slice, watch for problems, and ramp up automatically when the signal looks good. Rollouts are configured per policy. They turn a static or adaptive policy into a progressive delivery process — without changing your SDK code at all.

​
How a rollout works

When you start a rollout, Traffical records the current allocation bucket ranges as the target state. At each step, it scales every allocation’s range proportionally toward that target:
The ratio between allocations is preserved at every step. During forward auto-ramp, the bucket ranges grow monotonically toward the target state — users who land in treatment at 5% stay there at 10%, 50%, 100%. Stability holds as long as the rollout only moves forward. When the rollout moves backward — via rollback_one_step, full_rollback, a manual set-percentage to a lower value, or any other shrinking action — bucket ranges shrink and users near the edge fall out of the new range, reverting to the fallback policy or to the parameter default. That’s the intended behavior: a rollback should pull users back, not strand them in an allocation the rollout has decided to retreat from. A lower-priority fallback policy in the same layer catches traffic outside the rollout’s current ranges. For single-allocation rollouts, this is just “everyone not yet in the treatment gets the old behaviour”.

​
Configuring a rollout

In the dashboard, open a policy and add a rollout configuration:
  • Target percentage — usually 100.
  • Ramp — either continuous (incrementPercentage every windowSizeMinutes, 15 minutes by default) or scheduled (an explicit list of { percentage, scheduledAt } steps).
  • Health checks — metrics to evaluate before each step.
  • Rollback strategy — what to do if a health check fails.
The scheduler advances the rollout in the background. You don’t need any code changes between steps — your SDK just keeps resolving from the latest bundle.

​
Health checks

Health checks reference metric definitions, not raw events. Two flavours:
  • Absolute — compare the metric against a fixed threshold (e.g. error rate ≤ 0.1%).
  • Relative — compare against a baseline policy (e.g. conversion rate no worse than 5% below baseline).
Each check requires minimumExposures before it runs. If there’s not enough data yet, the rollout holds at the current step rather than passing or failing.

​
Rollback strategies

When a health check fails, the configured action fires:

​
Warm-up windows

With health checks configured, the rollout waits warmupWindows windows (default 2) at each step before it evaluates health and takes the next step. The new traffic level gets time to produce data the checks can judge. So a 15-minute window with the default warm-up steps every 30 minutes. Without health checks there is nothing to warm up for, and the rollout steps once per window: +10% every 15 minutes means every 15 minutes. The rollout card on the policy page shows the cadence that actually applies, for example +10% every 30 min (15 min × 2 warm-up), and Next Step shows when the next step is expected. It reads Due now when a step is due but hasn’t been taken yet. A step held back because a health check is still waiting for enough data moves to the next window.

​
Safety limits

  • maxStepsPerRun caps how many advances the scheduler will do in a single evaluation (default 3). This prevents “catch-up” jumps after an outage where the scheduler missed many windows.
  • Stable while ramping forward — when the rollout advances monotonically, ranges only grow, so no user is reassigned. When the rollout shrinks (manual lower percentage, rollback action), users near the new range edge fall back to the fallback policy or defaults.

​
When a rollout completes

When the rollout reaches its target percentage, the scheduler stops advancing. The onComplete action determines what happens to other policies in the same layer:
  • pause_lower_priority — lower-priority policies in the layer are paused (the rollout has effectively replaced them)
  • none — nothing happens; the rollout policy is now at full traffic alongside whatever else was running
You can also manually promote the winning allocation: set the parameter’s default to the winning value, mark the policy completed, and archive it.

​
Manual override

You can pause, resume, jump to a specific percentage, or roll back manually from the dashboard at any time. The scheduler respects whatever state you put the rollout in.

​
Lifecycle

You don’t need to do all four. A low-risk feature flag may go straight from rollout to complete. An adaptive policy can stay in learning mode indefinitely.
When Changes is enabled for your organization, this lifecycle is what a change runs for you: each phase — canary, experiment, rollout — executes as a governed phase policy, ramped in health-gated steps with an approved measurement plan attached.

​
Feature flags as rollouts

A boolean parameter with a rollout policy is a feature flag with built-in safety:
Start with a 5% rollout, attach a health check on your conversion-rate metric, and let the system ramp to 100% — automatically pausing if conversion drops. See Feature flags.

​
Next steps

Feature flags

Boolean parameters with rollout safety.

Progressive rollout pattern

Full walkthrough with metric setup.