How Long Should a Canary Bake? The Variable Nobody Sets in Their Canary Deployment Strategy
Ask a team to describe their canary deployment strategy and you'll get two numbers: the traffic percentage and the error threshold. We ramp to five percent, watch the error rate, and if it stays under some line we advance. What you almost never get is a third number — how long the change sits at each step before it's allowed to move. That number is usually either absent, delegated to whoever's watching the dashboard and getting impatient, or hard-coded to something like "ten minutes per step" that someone picked because it felt tolerable. It is the most consequential variable in the whole process, and it's the one nobody deliberately sets.
I want to argue that bake time — the dwell duration at each rollout step — is what actually validates a canary, and that percentage and error thresholds are close to worthless without it. A change at two percent traffic for eight minutes has not been validated. It has been observed, briefly, under whatever conditions happened to exist during those eight minutes. Those are not the same thing, and conflating them is why changes sail through a gradual feature rollout and then take production down at a hundred percent.
Validation is exposure, and exposure takes time
Here's the reframe. The question "how to validate a canary release before full rollout" is not really a question about metrics. It's a question about whether the canary has been exposed to the conditions that would reveal its failure mode. If the conditions that break the change never occurred during the bake, the metrics were green because nothing was tested — not because the change is safe.
And an uncomfortable number of production failure modes are time-dependent by construction. A memory leak doesn't manifest in eight minutes; it manifests when the process has been serving the new path long enough to exhaust its headroom. A connection-pool exhaustion bug needs sustained concurrency to surface. A caching change looks perfect while the cache is warm from the old path and only degrades as entries expire and the new path has to fill them cold. A slow query that's fine against a small working set becomes a problem as the relevant rows accumulate over hours. A change that touches a nightly batch job or an hourly cron literally cannot fail until that job runs — and if your canary baked between the runs, you validated nothing about the exact code path most likely to hurt you.
Then there's the traffic cycle. Most SaaS products have a diurnal shape: a quiet morning, a midday peak, a long tail into the evening, a near-empty overnight. A percentage rollout strategy for SaaS features that ramps to twenty-five percent at 2 p.m. and reaches a hundred by 3 p.m. has never seen the change under peak load, never seen it overnight when the batch pipeline runs, never seen it interact with the Monday-morning login surge. You proved the change survives a Tuesday afternoon. You ship it into a Friday evening. The canary passed a test that didn't include the failure.
Why teams under-bake, every time
If bake time is this important, why is it the variable nobody sets? Because the default mechanism for advancing a rollout is a human's patience, and patience is the wrong instrument.
When advancement is manual, the person watching the dashboard is the clock. They ramped to five percent, they've been staring at a flat error graph for a few minutes, nothing is happening, and something else needs their attention. So they advance — not because the evidence is sufficient, but because waiting is boring and expensive and the graph looks fine. Under-baking isn't a discipline failure any more than under-flagging is; it's a friction failure. Sitting and watching a healthy rollout for two hours is exactly the kind of high-cost, low-visible-reward work that always loses to whatever else is on fire. So the bake collapses to however long a human can stand to watch, which is far shorter than the failure modes require.
The fixed-timer version isn't better, just differently wrong. "Ten minutes per step" treats bake time as a constant when it's actually a function of the specific change and the specific traffic. Ten minutes is an eternity for a stateless UI tweak and criminally short for a change to a connection pool or a cache. A global dwell time is the same category error as a global error threshold: it pretends every change has the same risk shape when the entire point of progressive delivery is that they don't.
Bake time is a per-step evidence condition, not a duration
The right model isn't "wait N minutes." It's "advance when there's enough evidence, and evidence accrues with exposure." That turns bake time into a condition with two parts.
The first part is statistical. To distinguish a real regression from noise on your rare-but-important events — the failed checkout, the timed-out request, the empty result for a specific segment — you need enough of those events to have occurred at the current traffic level to reach reasonable confidence. At two percent traffic, the events you care about arrive slowly, so the dwell has to be longer, not shorter. This is the counterintuitive part teams get backwards: the smallest, safest-feeling early steps need the most patience, because that's where the denominator is thinnest.
The second part is coverage. The dwell at a given step should span at least one representative slice of your system's real behavior — a full traffic cycle if the change is load-sensitive, at least one execution of any periodic job the change touches, and enough time for any warm/cold state transition the change depends on to actually transition. If a change modifies something that only runs at 4 a.m., the honest bake time includes a 4 a.m. You either wait for the condition or you accept that you're shipping it untested.
Notice that this is where the "ship fast" objection dissolves. A long bake feels like it contradicts continuous delivery only when someone has to sit through it. But the change is already deployed — it's dark behind a flag, blocking nobody, costing nothing while it dwells at five percent overnight. The expensive thing was never the waiting. It was the human doing the waiting. Remove the human and bake time becomes nearly free, which means you can afford to bake for as long as the evidence actually requires instead of as long as someone can tolerate.
Making the bake automatic is the whole game
This is the part of a canary deployment strategy that has to move into the platform, because it's precisely the part humans do worst. Left to people, the bake is as long as attention lasts. Encoded in a system, it's as long as the evidence demands — and the system doesn't get bored at 2 a.m.
That's the model DeployRamp's rollout scheduler is built around. Advancement isn't a timer and it isn't a human deciding they've watched long enough; it's a per-step condition that waits for enough exposure to reach confidence on the metrics that matter for that specific change, holds through a representative traffic cycle when the change is load-sensitive, and only then widens the blast radius — pulling the flag automatically the moment the comparison against baseline turns. The percentage on the dashboard stops being the thing you trust. What you trust is that the change was actually exposed to the conditions that could break it before it reached everyone. A canary that passed in ten minutes never ran. A canary that baked until the evidence was in is the only kind that validated anything.