Course contentsShow
← Node.js
Lesson 1457 of 1,98013. Error Handling and Resilient SystemsFree lesson

Kubernetes Liveness Readiness Probes

You will map your application's internal health status to Kubernetes probe configurations for automated management.

Mastering Kubernetes Liveness and Readiness Probes

In this lesson, you will learn how to map your Node.js application’s internal health to Kubernetes probes to ensure your service is only receiving traffic when it’s truly ready and is restarted automatically when it becomes unresponsive.

Kubernetes doesn't know what’s happening inside your Node.js process; it only knows if the container is running. By configuring Liveness and Readiness probes, you teach Kubernetes how to monitor your application's internal state.

The Readiness Probe

A Readiness probe tells Kubernetes, "I am fully booted and ready to handle user requests." In a Node.js app, this often means your database connections are established and your internal caches are pre-warmed. If this probe fails, Kubernetes removes your Pod from the service load balancer, preventing users from hitting a half-initialized instance.

The Liveness Probe

A Liveness probe tells Kubernetes, "My process is healthy and not deadlocked." If this fails, Kubernetes assumes the application has entered a "zombie" or broken state and will forcefully kill and restart the container.

Implementation Pattern

You can expose these as dedicated health check endpoints:

// Express example
app.get('/health/ready', (req, res) => {
  const isDbConnected = db.isConnected();
  if (isDbConnected) {
    res.status(200).send('Ready');
  } else {
    res.status(503).send('Not Ready');
  }
});

app.get('/health/live', (req, res) => {
  // Check for event loop lag or deep deadlocks
  if (isEventLoopHealthy()) {
    res.status(200).send('Live');
  } else {
    res.status(500).send('Unhealthy');
  }
});

When setting these up in your Kubernetes YAML, ensure the initialDelaySeconds provides enough buffer for your app to start, and set the periodSeconds to balance responsiveness with overhead. Avoid doing heavy work inside the liveness check, as a slow check can trigger a false positive, causing your pod to crash-loop unnecessarily. By separating readiness (traffic eligibility) from liveness (process vitality), you create a self-healing system that gracefully handles temporary startup delays and permanent runtime failures.

Key Takeaway: Use readiness probes to signal service availability to the load balancer and liveness probes to trigger automatic restarts for unrecoverable runtime states.