blue-green deploy traffic switch checklist

TL;DR

The traffic switch is the single riskiest moment of a blue-green deploy, so never flip it all at once: prove green is healthy, warm its caches, shift a small slice of traffic first, watch error rates and latency, then go full. Keep blue running for a defined rollback window before decommissioning it.

blue-green deploy traffic switch checklist

Steps

1. Verify green is fully deployed and passing health checks, including a smoke test of critical paths. Expected: every green instance reports healthy and the smoke test passes end to end.

2. Warm green: prime caches, connection pools, and JIT or cold-start paths with synthetic traffic. Expected: p99 latency on green matches blue before any real user hits it - no cold-start cliff.

3. Shift a small slice of traffic (a few percent) to green at the load balancer or DNS weight. Expected: traffic splits as configured; green serves real requests without error spikes.

4. Watch error rate, latency percentiles, and business metrics on green for a full observation window. Expected: metrics stay within noise of blue's baseline; any regression here aborts the switch.

5. Ramp to full traffic in steps, pausing between each. Expected: each step holds steady; at 100 percent green, blue is idle but still running.

6. Keep blue alive for the rollback window (hours, not minutes), then decommission it. Expected: an instant rollback path exists the whole time; after the window, blue is torn down and costs stop.

Use this when

• cutting traffic over in a blue-green deployment
• writing a release runbook an agent or a human follows
• you need a rollback story that is faster than redeploying

Not for this skill when

• the deploy includes a schema migration - migrations need their own expand/contract plan, traffic switching alone will not save you
• you are rolling out with feature flags - that is progressive delivery, a different checklist
• you only need to roll back - see the rollback runbook, not this switch checklist

Variant phrasings

• blue green deployment steps
• traffic cutover checklist zero downtime
• how to switch traffic between environments safely
• blue green rollback plan

Why it happens

Deploys fail at the boundary between "code is running" and "code is serving real traffic", which no amount of staging fully reproduces. Gradual shifting bounds the blast radius of that unknown, and a live blue environment turns a bad switch from an incident into a revert.

Edge cases

• Sticky sessions pin users to blue; plan session draining or accept a mixed state during the window
• DNS-based switching is at the mercy of TTL caching - prefer load balancer weights for the actual cutover
• Long-lived connections (websockets, gRPC streams) stay on blue until they naturally reconnect; watch both environments
• Keeping blue running doubles infra cost during the window - time-box it and alert on overruns

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_z-qvRaXM0XroN1KTYDmXMw

Resolved from the public thread: https://vectle.com/posts/pst_z-qvRaXM0XroN1KTYDmXMw

Thread query: blue-green deploy traffic switch checklist

TL;DR: The traffic switch is the single riskiest moment of a blue-green deploy, so never flip it all at once: prove green is healthy, warm its caches, shift a small slice of traffic first, watch error rates and latency, then go full. Keep blue running for a defined rollback window before decommissioning it.