Kubernetes Liveness & Readiness Probes

Kubernetes Liveness & Readiness Probes

The Core Idea

Imagine you have a restaurant. The health inspector checks if the kitchen is safe to operate at all — that’s a Liveness Probe. The host at the door checks if the kitchen is ready to accept new orders right now — that’s a Readiness Probe.

Kubernetes uses these two probes to keep your applications healthy and your users happy.

Liveness Probe — “Are you still alive?”

A Liveness Probe answers one question: is this container fundamentally broken?

Sometimes apps hit a deadlock, run out of memory, or just freeze — they’re running but completely useless. Without a liveness probe, Kubernetes has no idea something went wrong. The container looks “up” from the outside, but it’s basically a zombie.

When a liveness probe fails, Kubernetes says “this is unrecoverable” and restarts the container. Think of it as a hard reset button that fires automatically.

yaml

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 10   # wait before first check
  periodSeconds: 5          # check every 5 seconds

Readiness Probe — “Are you ready for traffic?”

A Readiness Probe answers a different question: can this container handle requests right now?

Even a healthy app isn’t always ready. It might be warming up a cache, waiting for a database connection, or loading config files on startup. During that window, you don’t want Kubernetes sending users to it — that leads to errors.

When a readiness probe fails, Kubernetes quietly removes the pod from the load balancer rotation. No restart, no drama — it just stops sending traffic until the app signals it’s ready again.

yaml

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 3

The Key Difference, Side by Side

Three Ways to Probe

Kubernetes gives you three mechanisms to run these checks:

• HTTP GET — hits an endpoint, expects a 2xx/3xx response (most common)
• TCP Socket — checks if a port is open and accepting connections
• Exec Command — runs a shell command inside the container, expects exit code 0

A Simple Mental Model

Think of a new employee on their first day:

• The liveness probe is HR checking “did this person show up and are they conscious?”
• The readiness probe is the manager checking “has this person finished onboarding and can they take customer calls?”

You want both. One without the other leaves blind spots — either you’re sending traffic to an app that isn’t ready, or you’re never restarting one that’s silently broken.

Bottom line: Liveness keeps your pods from becoming zombies. Readiness keeps your users from hitting pods that aren’t ready yet. Together, they’re the backbone of self-healing applications in Kubernetes.