Skip to content
Optimal Lab

DevOps · interactive

Liveness and readiness probes

This app takes 20 s to warm up, and at 60 s it deadlocks: the process is alive but answers nothing. Kubernetes only knows what your probes tell it. Requests arrive every 5 seconds.

App state

Requests

0 s60 s (hangs)120 s
starting ready hung restarting not sent to this pod

17 failed requests · 0 restarts

Traffic hits the pod while it's warming up and after it hangs: 17 failed requests, and it never recovers.

Probes configured

Step 1 of 4

  1. 1

    Without probes, “running” means healthy

    Kubernetes sends traffic as soon as the process starts, and never notices a hang.

    Errors during warm-up, and forever after the hang.

  2. 2

    Readiness: should I get traffic?

    While the readiness check fails, the pod is taken out of the Service. Nothing is restarted.

    readinessProbe: httpGet /ready

  3. 3

    Liveness: should I be restarted?

    After a few failed checks, the container is killed and started again. Point it at something that fails only when the process is truly stuck.

    livenessProbe: httpGet /live, failureThreshold: 3

  4. 4

    Use both, and keep them different

    Readiness can check dependencies; liveness shouldn't, or a database blip restarts every pod. A startupProbe covers slow starts.

    Both: 0 errors, 1 restart.

In production

Tools and technologies

Probes are how Kubernetes decides to route to or restart a container.

Not tied to one language — use these names when you search docs or design a system.