Liveness vs Readiness vs Startup Probes in Kubernetes

Quick answer
A readiness probe decides whether a pod receives traffic; a liveness probe decides whether it gets restarted.
A startup probe protects slow-starting apps by disabling the other two until the app is up.
Without a readiness probe, Kubernetes routes requests to pods that have not finished starting.
A liveness probe that checks too much (like a database) causes restart storms during unrelated outages.
The health endpoint should be cheap, and it should reflect whether the app can serve, not whether the world is healthy.

What is a probe?

A probe is a periodic check Kubernetes runs against a container to learn something about its state. You define it in the container spec as an HTTP request, a TCP connection, or a command. Depending on the type, the result either adds or removes the pod from a Service’s endpoints, or restarts the container. They are the mechanism behind rolling updates and self-healing, and a manifest with no probes opts out of both.

What is the difference between liveness, readiness, and startup probes?

A readiness probe answers ‘should this pod get traffic right now?’. Failing it removes the pod from the Service without restarting it, which is what you want during warm-up or a transient dependency blip. A liveness probe answers ‘is this container stuck?’. Failing it restarts the container, so it should be a conservative check that only fails when a restart is genuinely the fix. A startup probe answers ‘has the app finished starting yet?’, and while it is pending the other two are suspended — the right answer for apps that legitimately take a minute to boot.

How do I write a readiness probe?

Point it at a health endpoint your app already exposes, and set conservative thresholds so a brief slow response does not eject a healthy pod.

containers:
  - name: api
    image: ghcr.io/acme/api:1.4.2
    ports:
      - containerPort: 3000
    readinessProbe:
      httpGet:
        path: /healthz
        port: 3000
      initialDelaySeconds: 5
      periodSeconds: 10
      failureThreshold: 3
    livenessProbe:
      httpGet:
        path: /livez
        port: 3000
      initialDelaySeconds: 20
      periodSeconds: 20

What goes wrong when probes are configured badly?

Three patterns cover most incidents. A missing readiness probe sends traffic to pods mid-startup, producing intermittent 502s during every deploy. A liveness probe that checks a database or an external API restarts every pod when that dependency has a hiccup, turning a partial outage into a full one. A startup probe set too aggressively, or a liveness probe with a short initial delay, kills containers that were simply slow to boot. The fix is to keep liveness about the process and readiness about serving traffic, and to test the endpoints return correctly when the app is healthy.

Where this bites vibecoders
Generated manifests routinely omit probes entirely, because a Deployment without them still runs. The absence is invisible until the first rolling deploy drops requests or the first pod gets wedged and never restarted. Conversely, an assistant asked to add health checks often wires the liveness probe to an endpoint that queries the database, which converts a database slowdown into a cluster-wide restart storm. Knowing which probe answers which question is the difference between resilience and a self-inflicted outage.

Where AI coding assistants get this wrong

Omitting probes from generated Deployments.
Making the liveness probe depend on the database or another service.
Setting a very short initialDelaySeconds on a slow-starting app.
Pointing probes at a port or path the app does not serve.
Using the same heavy endpoint for readiness and liveness.

Checklist

Add a readiness probe to every long-running workload.
Keep liveness checks about the process, not its dependencies.
Use a startup probe for apps that take more than a few seconds to boot.
Confirm the probe path and port match the app.
Watch for probe failures during a deploy and tune thresholds.

FAQ

Do I need both a liveness and a readiness probe?

They do different jobs: readiness controls traffic, liveness controls restarts. Most production services define both. If you only have one, make it readiness — sending traffic to an unready pod is the more common and more visible failure.

What happens if a container has no probes?

Kubernetes assumes it is ready as soon as it starts and never restarts it for being unresponsive. That works for trivial services and causes failed deploys and stuck pods for anything that takes time to start or can hang.

What is a good health endpoint?

A cheap endpoint that returns 200 when the process can serve requests, without doing expensive work or calling other systems. Split it: a liveness path that checks the process, and a readiness path that confirms required dependencies are reachable if you need that signal.