RELEASE ENGINEERING · TRAFFIC CONTROL ROOM
Deployment gate: evidence before promotion
Route individual requests, observe both versions and stop candidate traffic when the measured release gate fails.
Scroll the diagram horizontally to inspect every label. The panels below give the same state as text.
Your experiment
Change the allowed error-rate delta and minimum samples. Identify the difference between insufficient evidence, rejection and an observation within configured limits.
The preview is the computed end of this same replay. Capture a baseline, change one parameter and compare the cohort evidence. “Within limits” is not proof of safety or an automatic production promotion.
Recent request trace
Offline, seeded traffic exercise; no deployment, provider API or real flag service is used. Two requests per second are evaluated without a capacity queue. Control latency is 100–200ms; candidate latency spans 75–125% of its configured center. Outcomes use independent fixed pseudo-random streams. The gate requires enough samples in both cohorts, then rejects an excessive observed error-rate difference or candidate p95. It is not a statistical significance test. Metrics accumulate from start, without a sliding window, confidence interval or dependency failures. Shadow responses never serve users; safe handling of real side effects is not implemented. Google SRE: canarying releases.
A promotion gate needs two cohorts
This deployment gate sends a fixed share of one hundred twenty requests to a candidate while the rest stay on control. Promotion evidence is the comparison of the two observed cohorts: candidate error rate minus control error rate, and candidate p95 latency. The gate returns Insufficient samples until both cohorts reach Minimum samples per cohort, Reject candidate when either limit is exceeded, and Within configured limits otherwise. Stop candidate traffic on rejection turns a rejection into a rollback that sets later candidate share to zero.
Watch the opening canary fail
With a twenty-five percent canary and the candidate fault starting at ten seconds, the first candidate request is at 9.5 seconds. By twenty-five seconds the candidate has eight requests with four errors, fifty percent observed against about 0.9 percent for control, and the pipeline rolls back. Users saw five errors. Raise Allowed error difference to thirty points and the rejection still happens at the same moment: the gap is about forty-nine points, so a looser threshold does not rescue this candidate.
Promote nothing without a baseline
Set Initial candidate share to one hundred percent. All one hundred twenty requests go to the candidate, thirty-eight fail, and the gate reports Insufficient samples to the end because control has zero observations. A pipeline that ships everything to the new version cannot measure a regression relative to the old one. Return the share to twenty-five and set Minimum samples per cohort to thirty: rejection is delayed until fifty-seven seconds and user errors rise to twelve. Larger minimums buy confidence at the cost of exposure.
A passing candidate and a latency failure
Set Candidate error probability to two percent. The candidate receives thirty-one requests with zero errors, and the gate ends Within configured limits. Now raise Candidate latency center to 600 ms while keeping two percent errors: the observed candidate p95 is 726 ms, above the 500 ms Candidate p95 limit, so the gate rolls back at twenty-five seconds despite a clean error record. Control error probability, Candidate fault begins and the Blue/green cutover slider also change the run; cutover applies only in blue/green mode.
Inspect the trace and the limits
Play, Pause, Next request, Restart, Speed and Time inspect the same deterministic sequence; changing any input recomputes it and rewinds. Progressive mode adds twenty-five points of share every fifteen seconds and shadow mode copies requests without exposing users to candidate errors. Missing from the model: build, test and artifact stages, approvals, database migrations, warm-up, statistical confidence intervals and correlated failures. Treat the gate label as a teaching outcome, not a production promotion decision.