Uptime
Blue-green deploy
Blue-green deploy is a release method with two full stacks: one live, one idle. You ship to the idle one, test it, and flip traffic.
How it is measured
Measure the flip: seconds of errors during cutover, probe success on the green stack before the switch, and the time to flip back. Smoke test green with real routes, including login and checkout, before it takes traffic.
Track the cost of the idle stack and the state it shares. Database migrations that break the blue code make rollback impossible, so count how many releases kept the schema compatible with both sides.
Worked example
A Laravel booking tool keeps blue on port 8001 and green on 8002 behind nginx. At 21:00, v2.14 is deployed to green. A script hits /health, /book, and /pay on green and gets 200 each time. nginx reloads to point at green at 21:04, and error rate stays at 0.1 percent.
At 21:12 the payment webhook returns 500 for one provider. The flip back happens at 21:14: two minutes of bad webhooks, 17 retried later by the provider. The old stack was untouched, so there was nothing to rebuild.
How it differs
Blue-green deploy swaps all traffic at once between two whole stacks. A canary sends a small share to the new code first. Blue-green excludes gradual exposure, so a bad build hits everyone at the flip. Canary excludes a clean full-stack swap and needs traffic splitting.
Common errors
Sharing a database across incompatible schemas. Switching without warming caches. Forgetting background workers on the old stack. Deleting blue right after the flip. Treating a health endpoint as a full test.
In practice
Make every migration backward compatible for one release, and keep the previous stack alive for at least an hour after cutover. If you can only afford one extra environment, write the flip procedure first and rehearse it on staging.