Every release is a bet that the change is good. Sometimes you lose — a bug ships. The question that decides how much it costs isn’t whether you had bugs; it’s how many users were exposed before you caught it. Push to everyone at once (big-bang) and a bad release hits your whole user base. Roll it out to 1% first (a canary), watch your monitoring, and a bad release hits a hundredth of them before you roll back. The catch: the safer strategies take more stages, so they’re slower to reach everyone. Pick a strategy, ship a bug, and watch the blast radius — the deployment-safety trade-off every FDE makes, made playable.
big-bang → pilot → phased → canary · smaller first cohort = smaller blast · but more stages = slower
blast radius
How many users a bad release affects before it’s caught and rolled back. The thing a rollout strategy bounds.
canary
Release to a tiny cohort (e.g. 1%) first, watch the metrics, then widen only if it’s healthy.
phased rollout
Widen in steps (10% → 40% → 100%), pausing to check health between each stage.
rollback
Reverting to the last good version fast — what turns a caught bug from a disaster into a footnote.
rollout.js — expose a little, watch, then widen
Pick a strategy
1,000 users. Choose how to roll out the change, decide whether this release has a bug, then Deploy. If it’s buggy, your monitoring catches it in the first cohort — so the blast radius is the size of that first cohort. Smaller first cohort, smaller blast; but more stages to reach everyone.
—
blast radius
—
protected
—
stages
How it works
The lab is a tiny rollout simulator, and it makes concrete a trade-off that sounds abstract until it’s your bad release. Model the user base as a fixed population and a strategy as a sequence of cohorts — the fractions you expose at each stage. Big-bang is one cohort of 100%; a canary is 1%, then 9%, then 40%, then 50%. Now ship a change. If it’s healthy, every strategy eventually reaches 100% and no one is harmed — the only difference is how many stages it took. But if it’s buggy, the key assumption is that your monitoring catches the problem while the first exposed cohort is live and you roll back the rest. Under that assumption the blast radius equals the size of the first cohort: big-bang exposes everyone at once, so a bug hits 100%; a canary exposes 1%, so the same bug hits 1% and the other 99% are protected by the rollback. That’s a hundredfold difference in damage from the same bug, decided entirely by rollout strategy. The cost of that safety is time: the canary needs four stages of watching to reach everyone, where big-bang is instant. So the real decision is a dial between speed and blast radius, and where you set it depends on the stakes — a reversible cosmetic change can big-bang, but anything touching a customer’s money, data, or core workflow deserves a canary and a fast, rehearsed rollback. Two things make the whole strategy work regardless of which you pick: monitoring good enough to detect the problem in the first cohort (without it, gradual rollout just delays the pain), and a rollback you can execute in seconds (without it, catching the bug early doesn’t help). Gradual rollout, real monitoring, and a rehearsed rollback are three parts of one safety system.
1
A strategy is a sequence of cohorts
Big-bang exposes 100% at once. A canary exposes 1%, then widens. Each strategy reaches everyone eventually — the difference is the first cohort and the number of stages.
2
A healthy release harms no one
If the change is good, every strategy rolls out to 100% cleanly. The only cost of a cautious strategy here is the extra stages it takes.
3
A bug’s blast = the first cohort
When a release is buggy, monitoring catches it in the first exposed cohort and you roll back the rest. So big-bang hits everyone; a canary hits 1% and protects the other 99%.
✓
Trade speed for blast radius
Smaller first cohorts bound the damage but take more stages to reach everyone. The dial is set by stakes — plus the two things that make it all work: monitoring that detects fast, and a rollback you can run in seconds.
Big-bang blast
100% of users
Canary blast
~1% of users
Safety costs
more stages (time)
Requires
monitoring + fast rollback
The code
# A rollout strategy is just a cohort schedule
strategies = {
"big-bang": [100],
"pilot": [5, 95],
"phased": [10, 30, 60],
"canary": [1, 9, 40, 50],
}
cohorts = strategies[choice]
if release_is_buggy:
# monitoring catches it in the first cohort; roll back the rest
blast_radius = users * cohorts[0] / 100
protected = users - blast_radius
else:
blast_radius = 0 # healthy → everyone gets it, no harm
stages = len(cohorts) # the speed cost of caution
Quick check
1. You ship a buggy release big-bang (100% at once). What is the blast radius?
Big-bang exposes every user at the same instant, so by the time monitoring catches the bug, all of them have already hit it. Rolling back stops future harm but can’t un-expose the users who already got the bad release. Blast radius = 100%.
2. Why does a canary rollout bound the blast radius of a bad release?
A canary releases to a small cohort first and watches the metrics. If the release is bad, only that tiny cohort is affected before you halt and roll back — so the same bug that would hit 100% under big-bang hits ~1%. The cost is the extra stages to reach everyone.
3. What two things must be in place for a gradual rollout to actually help?
Gradual rollout only bounds blast radius if you can (a) detect the problem while the small cohort is live — otherwise you just delay the pain — and (b) roll back quickly once you do. Without monitoring and fast rollback, a canary is just a slower way to ship the same bug to everyone.
FAQ
What is a canary deployment?
Releasing a change to a small subset of users first (often 1%) while watching metrics. If the canary cohort stays healthy, you widen the rollout; if it shows problems, you halt and roll back, having exposed only that tiny group. Named for the "canary in a coal mine" — the small cohort is an early warning that bounds a bad release’s blast radius to the canary’s size.
What is the difference between a phased rollout and a big-bang deployment?
Big-bang ships to everyone at once — fastest, but a bad release hits your whole user base before you can react. Phased widens in steps (10% → 40% → 100%), pausing to check health, so a problem caught at 10% affects only that tenth. Phased trades speed for safety: more stages and time, but a bounded blast radius. Big-bang suits low-risk reversible changes; phased suits consequential ones.
Why does a rollout strategy need monitoring and fast rollback?
Because gradual rollout only helps if you notice the problem while it’s contained and can undo it fast. Without monitoring, a bad first-cohort release goes undetected and you widen anyway — a canary becomes a slow path to harming everyone. Without fast rollback, detecting doesn’t stop it. Gradual rollout, first-cohort monitoring, and a rehearsed one-command rollback are three parts of one safety system.
How should an FDE choose a rollout strategy at a customer?
By stakes and reversibility. A cosmetic, easily-reversible tweak can big-bang; anything touching money, regulated data, or a core workflow deserves canary/phased. Weigh the customer’s tolerance — early in a deployment, err toward caution, since one visible failure can sink trust. And ensure the prerequisites are real: gradual rollout needs monitoring and a fast, tested rollback in the customer’s environment, which is part of hardening for production.