Staged rollout

Releasing to a small group first, then expanding through planned percentages or cohorts over hours or days.

“release to 1% then 10% then everyone”“turn it on for more users each day”“slowly widen the launch”“phased release”“why did my friend get the update and I didn't”“staged rollot”“don't give the update to everyone at once”“start with employees then a few customers”

What it is

A staged rollout releases a change to expanding groups on a schedule: employees, then 1% of customers, then 10%, 50%, and everyone. The stages may be percentages, regions, account lists, or app-store cohorts, and each one gets time to reveal problems before the next opens. Apple calls the app-store version a phased release; Google Play calls it a staged rollout.

Reach for it when the change can be enabled independently for different users and a full launch would create too large a blast radius. It is broader than a canary release: a canary usually compares health metrics between old and new versions, while a staged rollout can simply control who gets access and when.

Gotcha: percentage assignment must be sticky. If a user lands in a new group on every request, they bounce between versions and produce bugs that neither version has alone. Keep old and new behavior compatible through the rollout, publish stop conditions before it begins, and make sure support can tell which stage a customer is in.

Ask AI for it

Create a staged rollout in LaunchDarkly for this feature. Use deterministic bucketing on the stable user ID, start with employees, then release to 1%, 5%, 25%, 50%, and 100% of customers with a 24-hour hold at each stage. Record the assigned variation in logs and support tools. Pause progression if error rate, p95 latency, or the feature's primary success metric crosses a written threshold, and keep one authenticated kill switch that returns everyone to the old behavior.

You might have meant

canary releasefeature flagdark launchautomated rollbackkill switch