Health check endpoints: liveness vs readiness and what to include

A single /health endpoint is used for both 'is the process alive' and 'is the app ready to serve traffic', causing Kubernetes to send traffic to starting apps or restart apps that are temporarily overloaded.

Implement separate liveness and readiness endpoints:

// Liveness: is the process alive? (Kubernetes restarts on failure)
// Keep this SIMPLE — only fail if the process is genuinely stuck
app.get('/health/live', (req, res) => {
  res.status(200).json({ status: 'alive', pid: process.pid });
});

// Readiness: can the app serve traffic? (Load balancer removes from pool on failure)
// Check all dependencies needed to serve a real request
app.get('/health/ready', async (req, res) => {
  const checks = {};
  let ready = true;

  try {
    await db.raw('SELECT 1');
    checks.database = 'ok';
  } catch (err) {
    checks.database = err.message;
    ready = false;
  }

  if (app.locals.startingUp) {
    checks.startup = 'in-progress';
    ready = false;
  }

  res.status(ready ? 200 : 503).json({
    ready,
    checks,
    version: process.env.APP_VERSION,
  });
});

// Kubernetes deployment.yaml
// livenessProbe:
//   httpGet: { path: /health/live, port: 3000 }
//   initialDelaySeconds: 30
//   periodSeconds: 10
// readinessProbe:
//   httpGet: { path: /health/ready, port: 3000 }
//   initialDelaySeconds: 5
//   periodSeconds: 5

A liveness probe that checks dependencies will restart pods unnecessarily when a dependency has a brief outage. A readiness probe removes the pod from the load balancer rotation instead.