Identify the supervisor’s stop signal and timeout. List the HTTP server, database pools, queue consumers and other resources the process owns.

1. Handle the supported termination signal in the application. Mark the instance unready so the proxy or load balancer can stop sending new requests.

2. Stop accepting new connections and allow in-flight requests an appropriate completion window. Set a finite deadline so shutdown cannot hang forever.

3. Close database pools and other resources after their active work completes. Pause queue consumption and preserve the retry or visibility behavior for unfinished jobs.

4. Coordinate the application deadline with the supervisor timeout. The supervisor must have enough time for the intended cleanup before forcing termination.

5. Test a restart during a harmless slow request and a queued task. Observe whether clients receive a controlled result and jobs recover as designed.

Adapt this fragment to an existing HTTP server. Its readiness handler must return unhealthy once stopping becomes true, and closeApplicationResources must be your implemented cleanup for pools and consumers. The 15-second deadline is an example to coordinate with the supervisor.

let stopping = false;
process.once('SIGTERM', () => {
  stopping = true;
  const deadline = setTimeout(() => process.exit(1), 15000);
  deadline.unref();
  server.close(async (error) => {
    try {
      await closeApplicationResources();
      clearTimeout(deadline);
      process.exitCode = error ? 1 : 0;
    } catch {
      process.exitCode = 1;
    }
  });
});

Test with a harmless slow request and an isolated queue task. Stop new work before draining existing work, and account for upgraded connections such as WebSockets separately. The process manager should allow the intended cleanup window.

Expected result: The old instance leaves service, in-flight work finishes or recovers according to policy, and the replacement becomes ready. A stuck resource cannot keep the old process alive indefinitely.

Confirm the replacement process starts, the old process exits and no abandoned connections accumulate. Check that external actions are not duplicated during job recovery.

If shutdown stalls, identify the open connection or timer holding the process alive. A forced exit may be necessary as a final bound, but it should not be the only planned path.

• Storing Express sessions outside process memory
• Using a queue for slow exports and notifications
• Deploying with a release directory and a controlled switch
• Deploying repeatable Node dependencies with npm ci

• Express graceful shutdown
• Node.js process signals

• Express health checks and graceful shutdown
• Node.js HTTP server reference