Feature flag SDKs like LaunchDarkly buffer analytics events locally and flush them to the platform on a configurable interval. These events are what LaunchDarkly uses to populate its Contexts list, track flag evaluations, support experimentation, and power guarded rollouts.

The Node.js server-side SDK has a specific behaviour worth knowing: unlike other LaunchDarkly SDKs, it does not automatically flush pending analytics events when it shuts down. You must call flush() explicitly before calling close(). If the process terminates without this, any events buffered since the last automatic flush interval are lost.

There is also a cost dimension. LaunchDarkly's pricing is based on client-side monthly active users (MAU) and server-side service connections. Analytics events are what the platform uses to track unique contexts. If events are consistently dropped on shutdown, context data becomes incomplete. In experimentation or guarded rollout scenarios, that lost data can skew results and affect decisions built on them.

When Kubernetes terminates a pod, it sends SIGTERM to PID 1 inside the container. In a Dockerfile with CMD ["npm", "run", "start"], PID 1 is npm, not Node.

npm receives SIGTERM and exits without forwarding the signal to its child processes. Node never receives the signal. The process.on('SIGTERM') handler in server code never fires. The SDK's close() method is never called. The connection leaks on every deployment.

# This makes npm PID 1 - signals stop here
CMD ["npm", "run", "start"]

This is a well-known footgun with npm as an entrypoint. It is also easy to miss because the container terminates eventually anyway via Kubernetes' SIGKILL after the grace period, so the application appears to stop correctly. The leak is invisible unless you are specifically watching for it.

tini is a minimal init system designed specifically for containers. It handles PID 1 responsibilities correctly: it forwards signals to its child processes and reaps zombie processes. Adding it means SIGTERM from Kubernetes reaches the child process rather than dying at npm.

RUN apk add --no-cache tini
ENTRYPOINT ["/sbin/tini", "--"]
CMD ["npm", "run", "start"]

This was necessary but not sufficient. tini forwards the signal to npm. npm still does not forward it to Node. The chain is one step longer but the same break exists at the npm boundary.

The real fix was a docker-entrypoint.sh script that bypasses the npm layer entirely and talks directly to the Node process.

#!/bin/sh
set -e

# Start Node directly in the background
node dist/server.js &
NODE_PID=$!

# Trap SIGTERM, find Node's PID, forward the signal directly
trap 'kill -SIGTERM $NODE_PID' TERM

# Wait for Node to exit cleanly
wait $NODE_PID

COPY docker-entrypoint.sh /usr/local/bin/
RUN chmod +x /usr/local/bin/docker-entrypoint.sh
ENTRYPOINT ["/sbin/tini", "--"]
CMD ["docker-entrypoint.sh"]

The full signal chain now works correctly:

Kubernetes sends SIGTERM to the container. tini receives it and forwards to docker-entrypoint.sh. The script's trap fires, finds Node's PID, and sends SIGTERM directly to Node. Node's process.on('SIGTERM') handler in server code fires. The SDK shutdown sequence runs.

With the signal chain fixed, the shutdown handler in server.ts now fires reliably. For the Node.js SDK specifically, the sequence must be explicit: flush first, then close.

process.on("SIGTERM", async () => {
  logger.info("SIGTERM received, starting graceful shutdown");

  try {
    await ldClient.flush();
    logger.info("LaunchDarkly events flushed successfully");
  } catch (err) {
    logger.error("LaunchDarkly flush failed", { error: err });
  }

  try {
    await ldClient.close();
    logger.info("LaunchDarkly client closed");
  } catch (err) {
    logger.error("LaunchDarkly close failed", { error: err });
  }

  process.exit(0);
});

Logging each step separately is deliberate. If flush() fails but close() succeeds, or vice versa, the logs tell you exactly which step broke and whether events were lost. A single catch around both operations collapses that information.