Zero-Downtime Deployment
Zero-downtime deployment rolls out a new version without taking the service offline, by running old and new side by side and draining the old as the new takes traffic.
Definition
Zero-downtime deployment is the rollout strategy where the new version is started and receives traffic before the old version is stopped, so that at no point is the service unavailable, achieved through rolling, blue-green, or canary rollouts with health checks gating the drain of the old instances.
Context and scope
Applied in continuous deployment, customer-facing services, and any system where a maintenance window is unacceptable.
Common misconceptions
- Zero-downtime means no errors — it means no downtime; some in-flight requests may fail during the switch unless connection draining handles them
- It requires no schema changes — it requires forward-compatible schema changes; a breaking migration cannot be zero-downtime without an expand-contract sequence
Anti-patterns
- Stopping old instances before the new ones pass health checks, so there is a gap with no healthy instance
- Deploying a version that cannot read the old version data format, so the new instances error on every in-flight request
Related concepts
Authoritative source
What it is
Zero-downtime deployment is the rollout strategy where the new version is started and receives traffic before the old version is stopped, so that at no point is the service unavailable, achieved through rolling, blue-green, or canary rollouts with health checks gating the drain of the old instances. Applied in continuous deployment, customer-facing services, and any system where a maintenance window is unacceptable. The unit of delivery is the deployable artifact plus its configuration, and the goal is to move changes to production safely, quickly, and reversibly.
How it works
Safety comes from small batches (less change per deploy means less blast radius), automated canaries (a bad change is caught at 1% before it reaches 100%), and reversible deployments (rollback is the default escape, not a rewrite). Speed comes from pipeline parallelism and eliminating the manual gates that batch up changes. Every step produces evidence — test results, scan output, canary metrics — that the next step consumes.
When to apply and pitfalls
Apply whenever the cost of an incident exceeds the cost of the pipeline that prevents it. The pitfall is optimizing deploy speed without investing in the observability and rollback that make speed safe — fast deploys of broken code just reach the outage sooner. Another is treating the pipeline as a checklist rather than a feedback loop that improves with each deployment.