Zero-downtime deploys, explained without the buzzwords
The mechanics behind a deploy nobody notices.
"Zero-downtime" sounds like a feature you buy, but it's really a property of how a deploy is structured: new and old versions of the service run side by side briefly, traffic shifts gradually from old to new, and nothing gets torn down until the new version has proven it's healthy.
Health checks have to reflect reality
A health check that reports healthy before a service is genuinely ready to serve traffic is one of the most common causes of a deploy that's technically zero-downtime but practically broken for the first few requests. The check needs to verify real readiness, not just that the process started.
Migrations must stay backward-compatible
Database migrations need to work with both the old and new code version for the duration of the rollout — because for a window of time, both are running against the same database. Skipping this compatibility window is where most 'zero-downtime' deploys quietly aren't.
Test the rollback as much as the rollout
Most zero-downtime failures aren't about the deploy tooling — they're about a rollback path that was never actually exercised and doesn't work when it's finally needed. Test it deliberately, on a schedule, not just when an incident forces the question.
- Zero-downtime is a property of deploy structure, not a tool you install.
- Database migrations need to stay backward-compatible during the rollout window.
- Test the rollback path as thoroughly as the deploy path.
Observability before you need it, not after the outage
HAVE A PRODUCT IN MIND?
Tell us what you're building and where you need engineering support.