{"post":{"slug":"zero-downtime-deployment-guide-2026","title":"Zero-Downtime Deployment 2026: Not Dropping Requests","excerpt":"Zero-downtime deployment is not one technique, it is a checklist of every place an in-flight request can get dropped during a restart. Here is the full 2026 checklist, from SIGTERM to load balancer deregistration.","category":"code","date":"August 10, 2026","author":"ByteLedger Team","content":"<span class=\"dropcap\">Z</span>ero-downtime deployment is not a single technique you switch on — it is a checklist of every point where an in-flight request can be dropped while an instance restarts, and closing each one. A request gets dropped when traffic keeps arriving at an instance after that instance has already started shutting down, or when the instance exits before it has finished the requests it already accepted. Getting this right is mostly about sequencing: stop new traffic, wait, finish existing work, then actually exit. Get the sequencing wrong and every deploy drops a handful of real requests, invisible in a dashboard showing overall uptime but very visible to the specific users who hit it.\n\n## What changed in 2026\n\n- **Container platforms tightened default grace periods.** Kubernetes, ECS, and Cloud Run all now make the gap between \"stop routing traffic here\" and \"kill the process\" more configurable and better documented by default.\n- **HTTP/2 and gRPC connection draining got real tooling support**, since long-lived multiplexed connections need explicit draining rather than simply waiting for a TCP connection to close.\n- **Readiness-gated rollouts became a default**, not an opt-in — most orchestrators now wait for a new instance's readiness probe to pass before removing an old one, tightening the whole rollover.\n- **Serverless platforms exposed shutdown hooks more consistently**, giving functions a documented, if short, window to finish work before a forced termination.\n\n## The sequence that actually prevents dropped requests\n\n1. **Orchestrator marks the instance as not-ready** and removes it from load balancer rotation, before sending any shutdown signal to the process itself.\n2. **Load balancer stops sending new requests**, but connections already established may still be sending traffic for a few seconds — this is the deregistration delay, and it must be longer than your slowest typical request.\n3. **The process receives SIGTERM** and immediately stops accepting new connections, while continuing to finish requests already in progress.\n4. **In-flight requests complete** within a grace period sized to the slowest realistic request the service handles, not the median.\n5. **The process exits**, or is forcibly killed (SIGKILL) if it exceeds the grace period — which should be rare, not routine, if the grace period is sized correctly.\n\nSkipping step 1, or making it happen at the same time as step 3 instead of before it, is the most common root cause of dropped requests during otherwise unremarkable deploys.\n\n## Readiness vs liveness vs the deregistration delay\n\n| Check | Question it answers | Failure response |\n| --- | --- | --- |\n| Liveness probe | Is the process alive and not deadlocked? | Restart the container |\n| Readiness probe | Should this instance receive traffic right now? | Remove from load balancer rotation, do not restart |\n| Load balancer deregistration delay | How long to keep draining connections after removal? | Traffic stops after the delay elapses, not instantly |\n\nConflating liveness and readiness is a common source of dropped requests: an instance that is alive but temporarily overloaded should fail readiness and get skipped, not be killed and restarted, which only adds more load to the remaining instances.\n\n## Common mistakes\n\n**Killing the process the instant SIGTERM is received.** Handle the signal, stop accepting new work, and let existing requests finish — the whole point of graceful shutdown is that \"stop\" and \"stop immediately\" are different operations.\n\n**Setting the load balancer deregistration delay shorter than your slowest request.** A five-second delay looks fine in a dashboard until a report-generation endpoint that takes eight seconds gets cut mid-response on every single deploy.\n\n**Not closing keep-alive connections during drain.** A client with a persistent HTTP connection can keep sending requests to an instance that thinks it has already stopped accepting new work, unless the server explicitly signals the connection should close after the current request.\n\n**Deploying schema-incompatible code alongside the deploy that requires it.** Zero-downtime deployment assumes old and new code run simultaneously for a window; see [database migration strategies for 2026](/blog/database-migration-strategies-2026) for keeping the database compatible with both during that window.\n\n## FAQ\n\n**How long should a graceful shutdown grace period be?**\nLong enough to cover your slowest realistic request with margin — often 30 to 60 seconds for typical web APIs, longer for services with long-running requests like report generation or file processing.\n\n**Does zero-downtime deployment require multiple instances?**\nYes, effectively — you need at least one instance still serving traffic while another restarts. A single-instance deployment cannot be zero-downtime by definition, no matter how well the shutdown sequence is tuned.\n\n**Is this the same as a rolling deployment?**\nRolling deployment is one strategy for achieving zero downtime, replacing instances gradually. Blue-green and canary strategies achieve the same request-level guarantee through different traffic-shifting mechanics; see [progressive delivery explained for 2026](/blog/progressive-delivery-explained-2026) for how those compare.\n\n**What is connection draining, specifically?**\nIt is the period during which an instance being removed from rotation is allowed to finish requests on connections it already holds, while receiving no new ones — distinct from the application-level graceful shutdown happening inside the process at the same time.\n\n## Where to go next\n\nSee [progressive delivery explained for 2026](/blog/progressive-delivery-explained-2026) for controlling how much traffic reaches new code in the first place, [database migration strategies for 2026](/blog/database-migration-strategies-2026) for keeping schema changes compatible during the deploy window, and [how to deploy a Next.js app in 2026](/blog/how-to-deploy-nextjs-2026) for a platform-specific walkthrough.","hue":322,"metaTitle":"Zero-Downtime Deployment Guide 2026","metaDescription":"Zero-downtime deployment for 2026: graceful shutdown, load balancer deregistration delay, readiness checks, and the sequence that prevents dropped requests.","keywords":["zero downtime deployment 2026","graceful shutdown deployment","rolling deployment without downtime","load balancer deregistration delay","readiness vs liveness probe","sigterm graceful shutdown","connection draining deployment","deploy without dropping requests"],"tldr":["**A dropped request during deploy is almost always a timing bug** — traffic keeps arriving at an instance for a moment after it starts shutting down.","**Graceful shutdown means finishing in-flight work, not exiting on SIGTERM** — stop accepting new requests, finish the ones already running, then exit.","**Load balancer deregistration needs a delay, not an instant cut** — the balancer must stop sending new traffic before the instance is allowed to stop.","**Readiness and liveness checks answer different questions** — liveness asks if the process is alive; readiness asks if it should receive traffic right now.","**Skip:** a fixed short shutdown timeout copied from a template — size it to your slowest real request, not a guess, or that request gets cut off mid-response."],"readTime":"4 min read","wordCount":896},"related":[{"slug":"expand-contract-migrations-2026","title":"Expand and Contract: Schema Changes Without Downtime","excerpt":"Renaming a column in one deploy breaks every running instance of the old code. Splitting the change into three deploys makes it invisible to users.","category":"code","date":"August 13, 2026","author":"ByteLedger Team","readTime":"5 min read","hue":320},{"slug":"graceful-shutdown-explained-2026","title":"Graceful shutdown explained in 2026: draining without data loss","excerpt":"A graceful shutdown stops a process without dropping work in flight. This 2026 guide covers SIGTERM versus SIGKILL, the four-step drain pattern, grace periods, and the pitfalls that lose data.","category":"code","date":"June 29, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":260},{"slug":"blue-green-deployment-vs-rolling-update-2026","title":"Blue-Green Deployment vs Rolling Update in 2026","excerpt":"Blue-green deployment and rolling updates both aim to ship code without downtime, but they trade off cost, rollback speed, and blast radius very differently. Here is how to choose.","category":"code","date":"July 5, 2026","author":"ByteLedger Team","readTime":"4 min read","hue":200}],"sameCategory":[{"slug":"bazel-build-explained-2026","title":"Bazel Explained: What Hermetic Builds Actually Cost","excerpt":"Bazel delivers reproducible, precisely cached builds and demands that you describe everything. Here is what you get, what it costs, and who should say no.","category":"code","date":"August 19, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":145},{"slug":"graphql-federation-2026","title":"GraphQL Federation: One Graph, Many Teams","excerpt":"Federation composes independently-owned subgraphs into a single API. Here is what it solves, the operational cost it adds, and when a simpler gateway is enough.","category":"code","date":"August 19, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":300},{"slug":"hermetic-builds-explained-2026","title":"Hermetic Builds Explained: Same Inputs, Same Output","excerpt":"A hermetic build depends only on declared inputs. Here is what that property gives you, the common leaks that break it, and how to move toward it incrementally.","category":"code","date":"August 19, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":130},{"slug":"monorepo-tooling-compared-2026","title":"Monorepo Tooling Compared: What You Actually Need","excerpt":"Monorepo tools solve task orchestration and caching, not repository layout. Here is what each tier provides and how to tell when you have outgrown the simple option.","category":"code","date":"August 19, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":150}],"newer":{"slug":"zapier-vs-ai-agents-2026","title":"Zapier vs AI Agents in 2026: When Simple Wins","excerpt":"An AI agent is not always the better tool. Here's a fast, practical way to decide when a deterministic zap beats an autonomous agent on cost, reliability, and how much you actually trust the output.","category":"ai","date":"August 10, 2026","author":"ByteLedger Team","readTime":"5 min read","hue":203},"older":{"slug":"zettelkasten-method-explained-2026","title":"The Zettelkasten Method Explained for 2026","excerpt":"Zettelkasten means a network of small, linked notes instead of folders of long documents. Here is how the system actually works, and why the links matter more than the notes themselves.","category":"guides","date":"August 10, 2026","author":"ByteLedger Team","readTime":"4 min read","hue":315}}