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

Think of a cashier at a busy railway reservation counter.

• Readiness: the cashier has stepped away to count cash, so the "counter closed" board goes up. Nobody is fired; people are just sent to other counters until the board comes down.
• Liveness: the cashier has fallen asleep and no amount of knocking wakes them. The supervisor replaces them with a fresh person.
• Startup: a new cashier needs ten minutes to log in and set up. The supervisor does not start knocking until setup is done.

Readiness controls traffic. Liveness controls restarts. Startup protects slow boots.

apiVersion: v1
kind: Pod
metadata:
  name: api
spec:
  containers:
    - name: api
      image: example/api:1.4.0
      ports:
        - containerPort: 8080
      startupProbe:
        httpGet:
          path: /healthz
          port: 8080
        periodSeconds: 5
        failureThreshold: 24     # up to 120 seconds to start
      livenessProbe:
        httpGet:
          path: /healthz
          port: 8080
        periodSeconds: 10
        timeoutSeconds: 2
        failureThreshold: 3      # restart after about 30 seconds of failures
      readinessProbe:
        httpGet:
          path: /ready
          port: 8080
        periodSeconds: 5
        failureThreshold: 2

In a real app these probes go inside a Deployment's Pod template. /healthz returns 200 if the process is alive and responsive. /ready returns 200 only when the app has finished loading config and warming caches and can serve requests.

The kubelet on each node runs the probes. A probe can be an HTTP GET (success is a status from 200 to 399), a TCP connection check, a command run inside the container (success is exit code 0), or a gRPC health check.

• Liveness fails failureThreshold times in a row: the kubelet kills the container and restarts it according to the Pod's restart policy. Repeated failures show up as CrashLoopBackOff with growing delays.
• Readiness fails: the Pod is marked not ready and removed from the Service's endpoints, so no new traffic is sent to it. The container keeps running, and when the probe passes again it is added back. Readiness is checked for the whole life of the Pod, not only at startup.
• Startup probe: while it is running, liveness and readiness are disabled. Once it succeeds, the others take over. If it never succeeds within its threshold, the container is restarted.

Readiness also gates rolling updates: a Deployment counts a new Pod as available only after it is ready, so a broken version stalls instead of replacing all the healthy Pods.

A Java service that takes 90 seconds to load gets a startup probe so liveness does not kill it at second 30, which would cause an endless restart loop. During a traffic spike, an overloaded Pod can fail readiness briefly to shed load while the other replicas keep serving. A Pod with a deadlocked thread pool still has a running process, but the liveness endpoint times out and Kubernetes restarts it automatically at night without anyone being paged.

• Checking the database in the liveness probe. If the database goes down, every Pod fails liveness and restarts together, which makes the outage worse and does nothing to fix the database. Liveness should check only the process itself.
• Using the same endpoint and settings for liveness and readiness without thinking about what each failure should do.
• Aggressive timeouts. A one-second timeout under garbage-collection pauses or heavy load causes needless restarts.
• No readiness probe, so traffic hits Pods before they can serve and users see errors during every deploy.
• Using a huge initialDelaySeconds on liveness instead of a startup probe.

• What happens during a rolling update if the new Pods never become ready?
• Should a readiness probe check downstream dependencies?
• What does CrashLoopBackOff mean and how do you debug it?
• How do you shut a Pod down gracefully so in-flight requests are not dropped?