What is the difference between liveness and readiness probes?

A liveness probe decides whether to restart a container — failures kill and recreate it. A readiness probe decides whether the Pod receives traffic — failures remove it from Service endpoints without restarting it. A deadlocked but alive process needs liveness; a warming-up process needs readiness.

When should I use a startup probe?

Use a startup probe for slow-starting containers (legacy apps, large JVMs). While it runs, liveness and readiness probes are disabled, so the app gets up to failureThreshold × periodSeconds to boot without being killed by an over-eager liveness probe.

What action handlers can a probe use?

Four: httpGet (HTTP 200–399 is success), exec (command exit code 0 is success), tcpSocket (TCP connection opens) and grpc (the gRPC health check returns SERVING). Exactly one handler is set per probe.

What HTTP status counts as a successful httpGet probe?

Any response code greater than or equal to 200 and less than 400 is a success. Codes 400 and above, or no response within timeoutSeconds, count as a failure toward failureThreshold.

How do the timing fields interact?

initialDelaySeconds waits before the first probe; periodSeconds is the interval; timeoutSeconds bounds each attempt; failureThreshold consecutive failures trigger action; successThreshold consecutive successes mark it healthy (must be 1 for liveness and startup).

Kubernetes Probe Types Reference

Email me this result

Get this tool's output sent to your inbox, plus one useful tool a week. No spam, unsubscribe any time.

Kubernetes probe types

Probes are how the kubelet checks container health. There are three probe roles — liveness, readiness and startup — each able to use one of four action handlers. Getting the role and timing right is the difference between graceful rolling updates and restart storms. This reference covers all three roles, the four handlers and every timing field.

How it works

You attach a probe to a container in the Pod spec. The kubelet runs the chosen handler on periodSeconds, and after failureThreshold consecutive failures it acts according to the probe’s role:

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5
  timeoutSeconds: 1
  failureThreshold: 3

Liveness failure → kubelet restarts the container.
Readiness failure → kubelet removes the Pod from Service endpoints (no traffic) but does not restart it.
Startup failure → like liveness, but while it is still passing/running the other two probes are suppressed, giving slow apps time to boot.

Success per handler: httpGet = HTTP 200–399; exec = exit code 0; tcpSocket = the TCP connection opens; grpc = the standard gRPC health check returns SERVING.

Tips and notes

Never point a liveness probe at a dependency (database, downstream API) — a blip there will restart-loop your whole fleet.
successThreshold must be 1 for liveness and startup probes; only readiness may require multiple consecutive successes.
A startup probe’s total grace is failureThreshold × periodSeconds — size it to the worst-case boot time.
terminationGracePeriodSeconds can also be set on a probe to override the Pod’s value when a failing liveness probe kills the container.