BLUE/GREEN · PER-VERSION MEASUREMENT
Blue/green observability: measure both versions
Mirror a slice of traffic to the green candidate and see whether the release gate is measuring green or a blended dashboard.
Your experiment
Blue serves 2,000 requests a minute at 1% errors and p95 320 ms. Green fails 3% of requests, so it violates the 2% objective. Start with one unlabeled series, add the version label, then vary the mirrored sample, the latency and the gate threshold.
Play replays the computed run over sixty inspection seconds; Next event steps, Restart rewinds, Speed changes the pace and Inspection time scrubs. Any input change recomputes the run and rewinds it without autoplay.
Event trace
Computed data
Final metrics
Deterministic model: error counts are the expected count rounded down, every green request has the same latency and blue p95 is fixed at 320 ms, so the blended p95 shows green only when green exceeds 5% of the requests. The objective (2% errors, p95 500 ms) defines the true answer; the error gate is what the release automation checks. No metrics backend or deployment is used.
A blended series hides the candidate
Blue serves 2,000 requests per minute at 1% errors and p95 320 ms. Green truly fails 3% of requests, which breaks the 2% objective. With the opening settings 100 requests are mirrored to green and 3 of them fail, but the dashboard has one series with no version label: it shows 23 errors in 2,100 requests, 1.1%, under the 2% gate. The gate switches all traffic to green, the first full minute produces 60 failed user requests, and the result is WRONG SWITCH. The regression was measured; it was averaged away.
Label the series by version
Set Dashboard series to Grouped by version label. The gate now reads the green series alone, 3% errors, and holds the release: CORRECT HOLD. Set Requests mirrored to green before the switch to 0: the green series is empty and the gate holds for lack of evidence, while the unlabeled dashboard shows blue alone at 1% and switches. An empty series must block a release; a blended one cannot even show that it is empty.
Sample size and rounding
With version labels, set Green true error rate to 2.5%: 100 mirrored requests yield 2 failures, exactly 2%, so the gate passes a release that breaks the objective. With 3% and only 50 mirrored requests, 1 failure also reads as 2%. Small verification samples understate rare errors; the gate threshold and the sample size have to be chosen together. A green error rate of 1.5% is healthy and switches correctly.
Latency hides until green is large enough
With version labels and a healthy 1% green, set Green latency, every request: 900 ms holds the release and 450 ms switches. On the unlabeled dashboard the blended p95 stays at blue’s 320 ms while green is under 5% of the traffic, so 100 mirrored requests hide a 900 ms green; 150 requests are 7% of the traffic and the blended p95 jumps to 900 ms. Gate: maximum error rate trades the two failures: at 0.5% even the blended 1.1% holds the regression, but a perfect green at 0% then reads 0.95% blended and is held wrongly.
Reading the run and its limits
Play, Next event, Restart, Speed and Inspection time step through the setup, the verification minute, the dashboard, the gate, the cutover and the verdict across sixty seconds; the table compares blue, green and what the dashboard shows. Error counts are expected values rounded down, green latency is one fixed value and blue p95 is fixed, so the percentile arithmetic is exact rather than sampled. The model shows which series a gate needs; it is not a statistical test.