Progressive Rollouts and Canary Releases Explained

A progressive rollout releases a change to a growing slice of the audience, commonly in stages such as 1%, 5%, 25%, 50%, and then 100%, checking a fixed set of guardrail metrics before advancing to the next stage. A canary release is a narrower, infrastructure-focused version of the same idea: a new build of the software runs in parallel with the stable one on a small subset of servers or instances, and the decision to expand traffic is usually automated by error and latency alarms rather than decided by a person watching a dashboard. Both patterns exist to answer the same question before a change reaches everyone: does this break anything in production, not which version performs better. This guide walks through what each pattern actually is, the feature flags infrastructure both usually sit on top of, the guardrail metrics and rollback triggers that decide whether a stage advances or reverts, typical rollout curves, and exactly where the boundary with A/B testing sits.

What a progressive rollout is

A progressive rollout (also called a gradual or phased rollout) exposes a new feature, or a new version of an existing one, to a small fraction of the audience first, then increases that fraction in discrete steps until it reaches everyone. The obvious alternative, flipping the switch for the entire audience in one shot, turns any unnoticed bug into a full-scale incident. A progressive rollout turns the same bug into something that affects a small, controlled slice, with time to react before it becomes a headline.

LaunchDarkly’s documentation draws a useful distinction between two related mechanisms. A plain percentage rollout sets a fixed slice of traffic manually (say 5%) and increases it by hand as confidence grows, keeping the same group of users allocated as long as that value does not change. A progressive rollout proper is different: the platform increases the percentage automatically over a defined window, for example moving a variation from 5% up to 100% over 24 hours in a series of scheduled steps. One detail LaunchDarkly’s own documentation calls out matters in practice: restarting a progressive rollout can allocate a different set of users to the new variation than the original run, because assignment is re-randomized every time the rollout starts, while a simple percentage rollout keeps serving the same group as long as the configuration itself is untouched.

In practice, most documented rollouts follow a version of the same sequence, adjusted to traffic volume and how much risk a team is willing to carry: an internal stage first (team and QA only, no real user exposed yet), then roughly 1% of production, then 5 to 10%, then 25 to 50%, and only then 100%. Flagsmith’s own guide on deployment strategies describes exactly this pattern with a concrete example: a flag enabled for 1% of users and, if the metrics look healthy, increased to 5%, then 20%, and onward until it reaches everyone.

What a canary release is, and where the name comes from

Canary release is a specific technique for reducing the risk of putting a new version of software into production, by releasing it slowly to a small subset of infrastructure before expanding to the rest, according to Martin Fowler’s definition on his bliki, the most commonly cited reference on the pattern. The name comes from a historical mining practice: miners carried canaries into coal mines as an early warning system, because the bird would die from toxic gas before the concentration became lethal for a person, giving the crew time to evacuate before the danger reached them. A canary release plays the same role in software: it exposes a problem to a small, controlled group before it can affect everyone else.

Fowler describes canary release as a close relative of blue-green deployment. Both start the same way: the new version is deployed to separate infrastructure with no real user traffic pointed at it yet. The difference shows up after that. In blue-green deployment, the switch is complete and immediate, all traffic moves from one environment to the other at the same instant, once validation has finished. In a canary release, real user traffic is routed to the new version gradually and incrementally, usually starting with a small random sample, then internal staff, and only then expanding by demographic, geographic, or organizational grouping, always keeping the option to revert quickly if something looks wrong.

Cloud provider documentation shows the same pattern in concrete, numeric form. AWS documents canary deployment for Lambda functions using a weighted alias that splits invocations between two published versions by percentage, and its own AWS SAM deployment presets ship predefined canary and linear configurations, such as shifting an additional 10 percent of traffic to the new version every 2 minutes (a preset AWS names Linear10PercentEvery2Minutes), with a CloudWatch alarm wired in advance to trigger an automatic rollback of all traffic back to the previous version if a threshold is breached during that window. It is the same logic as the canary in the mine: a small, controlled warning signal before the risk can spread to everyone.

Progressive rollout vs canary release: what actually differs

Progressive rollout and canary release share the same underlying principle, expose gradually, monitor, decide, but they focus on different layers of the system and are frequently owned by different teams.

Criterion	Progressive rollout (feature flag)	Canary release
Primary focus	Users and functionality: who sees what	Infrastructure and deploy: which version of the code is live
Who decides to advance	Usually a person (product, engineering), manual or rule-based	Usually automated, driven by error/latency metrics from the deploy pipeline
Unit of segmentation	User, account, or session, with stable ID-based assignment	Server, instance, pod, or slice of infrastructure
What is being validated	Whether the feature behaves well for the business and the user	Whether the new code version is stable in production (errors, latency, service health)
Typical tooling	LaunchDarkly, Unleash, Flagsmith, PostHog, Statsig	Deploy pipeline (AWS CodeDeploy/ECS, Kubernetes, Google Cloud Deploy)
Rollback mechanism	Turn the flag off, usually in seconds	Redirect traffic back to the previous stable version

A simple way to remember the difference: canary release answers whether that version of the code is safe to run in production, while a feature-flag progressive rollout answers whether that functionality is safe for people to use. In practice the two combine often: you deploy the new version through a canary release (the code is already running, validated against a subset of infrastructure), and layer a feature flag on top to control who, within that already-deployed code, actually sees the new functionality. Canary controls where the code runs; the feature flag controls what shows up for whom.

Guardrail metrics: what decides whether a stage advances

The element that turns a rollout from “raise the percentage and hope” into a defensible engineering practice is the set of guardrail metrics: indicators that are not allowed to get worse while exposure increases. The ones most commonly cited across deploy and feature-management documentation are error rate, latency (particularly the high percentiles, p95 and p99, because an average hides the worst individual cases), crash rate on mobile apps, and a business indicator, such as conversion rate or payment failure rate, whenever the change can plausibly touch revenue.

LaunchDarkly formalizes this under what it calls a guarded rollout: the platform increases exposure to a new variation step by step while comparing it statistically against the original on every connected metric (via integrations, API imports, SDK events, or OpenTelemetry traces), using sequential testing to flag a regression only once the confidence interval sits entirely on the worse-performing side, not on every random blip along the way. When a regression is confirmed, the rollout pauses and notifies the responsible team; with automatic rollback enabled, the platform reverts the exposure itself instead of waiting for a person to act on the alert.

AWS’s implementation of the same idea for Lambda functions is more numeric: a CloudWatch alarm defined before the rollout starts, an error rate above a threshold sustained for a few minutes is the most common trigger, automatically shifts all traffic back to the previous version if it fires during the validation window. The window itself is deliberately short enough to catch a real regression but long enough not to confuse a transient traffic spike with an actual problem.

Rollback triggers: when to pull back, not push forward

Rollout stage	Guardrail metric to watch	Rollback trigger
Internal / dogfood	Obvious functional errors, exceptions in logs	Any reproducible bug, before real users are exposed at all
1%	Error rate, latency p95/p99	Error rate or latency exceeds baseline by a defined threshold, sustained past a short window
5-10%	Same technical metrics, plus an early business signal	Technical metric still degraded, or an early conversion/payment anomaly shows up
25-50%	Business metrics start carrying real statistical weight	Sustained business-metric regression, not a single noisy data point
100%	Full audience; the flag becomes a removal candidate	Any confirmed regression still triggers a full revert, exactly as at any earlier stage

The pattern that shows up consistently across LaunchDarkly’s documentation, AWS’s canary tooling, and Unleash’s own comparison of canary release versus rolling deployment is this: canary-style rollback is close to instantaneous, because it just means redirecting traffic back to a version that is already running, while a rolling deployment that has already replaced instances in place needs a slower, reverse deployment to undo the same change. That speed difference is exactly why canary release and guardrail-driven feature flag rollouts get recommended for anything with real blast radius, and it is why the answer to a degrading guardrail metric is always to reduce exposure, never to keep advancing and hope it stabilizes on its own.

How this relates to (but is not) A/B testing

It is worth being explicit about a common mix-up: a progressive rollout is not an A/B test, even though the two frequently run on the same feature flag infrastructure under the hood. An A/B test allocates traffic to a fixed split between variations, the same slice in every arm from the first visitor to the last, with a sample size and a significance threshold calculated before the test starts, and it ends with a statistical decision about which variation performs better. A progressive rollout increases the exposed slice over time until it reaches 100%, and it ends when the change is live for everyone, not when a winner has been statistically proven. The two mechanisms look similar, a rule deciding who sees what, but they answer different questions. The full breakdown of exactly where that line sits, and when a plain rollout should graduate into a real experiment, lives in feature flags vs A/B testing.

The same distinction carries over to the execution layer. As covered in our comparison of client-side vs server-side A/B testing, a product-level progressive rollout is normally decided server-side, on the same infrastructure that powers server-side feature flags, because it usually touches business logic, permissions, or sensitive data that should not be evaluated inside the visitor’s browser. A canary release, by contrast, is always an infrastructure decision: it happens at the deploy layer, before any flag even decides what appears to whom.

One more distinction worth making explicit: a guardrail metric holding steady is not statistical proof that a change is an improvement. It only means the change did not visibly break anything at that stage, which is a much lower bar than the confidence interval and p-value, or Bayesian probability, that an actual A/B test produces. If the guardrail metric of interest is itself a conversion rate and the real question shifts from “did this break something” to “did this actually convert better,” that question calls for a proper significance test, not a rollout dashboard. The A/B test significance calculator on this blog runs exactly that calculation once you have a real control group to compare against.

Automate This on Donnu

Everything a progressive rollout or a canary release tells you is a negative result dressed up as good news: the change did not obviously break anything at this stage. That is valuable, and worth doing before every meaningful release, but it is a different claim from “this version converts better than the one it replaced,” and treating a clean rollout as proof of a positive effect is one of the most common mistakes teams make once a feature is fully live. A guardrail metric holding steady at 100% tells you the deploy was safe. It says nothing about whether the change actually moved the number you care about, because there was no control group running at the same time to compare against.

That is exactly the gap Donnu A/B is built to close. Once your rollout reaches a stage where you actually want to know if a variation performs better, not just whether it is safe, Donnu runs a real controlled experiment behind the same kind of stable, flicker-free targeting a rollout already needs: a calculated sample size, both versions running side by side for the same audience over the same time window, and an honest Bayesian read at the end instead of a guess based on a dashboard that looks fine.

Start a 14-day free trial and turn your next release from “it didn’t break” into “we know it works.” For the base layer this guide builds on, see the complete guide to feature flags; for the exact line between a rollout and a real experiment, see feature flags vs A/B testing.

References

• Fowler, M. CanaryRelease. martinfowler.com/bliki, 2014. martinfowler.com/bliki/CanaryRelease.html.
• LaunchDarkly. Progressive rollouts and Guarded rollouts. launchdarkly.com/docs/home/releases/progressive-rollouts and launchdarkly.com/docs/home/releases/guarded-rollouts.
• AWS. Implement Lambda canary deployments using a weighted alias. docs.aws.amazon.com/lambda.
• Unleash. Canary release vs rolling deployment: Rollback speed, risk, and resources. getunleash.io/blog.
• Flagsmith. 8 Types of Deployment Strategies (And How Feature Flags Help). flagsmith.com/blog.

---

Read next: The complete guide to feature flags . Feature flags vs A/B testing . Client-side vs server-side A/B testing. Leia em português: Rollout progressivo e canary release, explicado.