errors-reliabilityAnswer last reviewed July 2026

Walk me through what a graceful shutdown actually looks like for a Node HTTP service.

A strong answer sequences the whole shutdown, from the readiness flip at the load balancer through keep-alive teardown, all bounded by a hard deadline

What an AI-prepared candidate might say

So the basic idea is you listen for SIGTERM, stop taking new work, let whatever's in flight finish, release your resources, and exit. Concretely you register a process.on('SIGTERM') handler, call server.close() so the server stops accepting new connections while the existing requests complete, then close your database pools and other clients, and exit with code 0. You also add a timeout so one stuck request can't block shutdown forever, like if the drain hasn't finished in ten seconds or so, you just force-exit anyway. In Kubernetes this lines up with the pod lifecycle. The platform sends SIGTERM, waits out the termination grace period, then sends SIGKILL if the process is still alive. And I'd handle SIGINT the same way so local development stays consistent with production.

Senior
Locked

Why server.close() can sit waiting forever on a perfectly healthy server, and the two connection-reaping methods Node added in 18.2 that actually finish the job.

Unlock the depth
Staff
Locked

The full drain ordering, the two race windows hiding inside it, and the deploy-time 5xx forensics that tell you which window you got wrong.

Unlock the depth
Follow-up chain
Walk me through what a graceful shutdown actually looks like for a Node HTTP service. | NodeBook