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).

What is the Kubernetes Probe Types Reference?

Reference for Kubernetes container probe types — liveness, readiness, startup — with their action handlers, timing parameters and effect on traffic and restarts. It runs free in your browser on Gera Tools, with nothing uploaded.

Kubernetes Probe Types Reference

Name: Kubernetes Probe Types Reference
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

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.

All timing parameters

Parameter	Default	Effect
`initialDelaySeconds`	0	Seconds to wait after container start before first probe
`periodSeconds`	10	How often to run the probe
`timeoutSeconds`	1	Seconds to wait for a probe response before counting as failure
`failureThreshold`	3	Consecutive failures before taking action (restart or remove from endpoints)
`successThreshold`	1	Consecutive successes to mark healthy (must be 1 for liveness/startup)

Important: failureThreshold × periodSeconds is the window within which an unhealthy container is detected and acted on. With defaults (3 × 10 = 30 seconds), a deadlocked pod can receive traffic for up to 30 seconds after it stops responding. Tune these values based on your acceptable downtime window.

Common mistakes and how to avoid them

Liveness probe pointing at a dependency. The most damaging misconfiguration. If your liveness probe calls your database or a downstream API, a transient network blip or brief dependency outage will restart-loop your entire fleet simultaneously. A liveness probe should only check whether the process itself is alive — not whether everything it depends on is working.

initialDelaySeconds too short. A JVM application may take 30–60 seconds to boot. With the default initialDelaySeconds: 0, the liveness probe fires before the app is ready and kills it repeatedly in a crashloop. Set initialDelaySeconds to slightly more than your worst-case startup time, or better — use a startup probe to handle slow starts cleanly.

No startup probe for slow starters. Legacy applications, large JVMs, or apps that warm up caches at startup are best paired with a startup probe. While the startup probe is active, liveness and readiness probes are suppressed, so the app gets the full failureThreshold × periodSeconds window to boot without interference.

Readiness same as liveness. Some teams copy the same probe spec for both. While this works, a readiness probe should be stricter — it can check downstream dependency availability to pull the pod from load balancing when a dependency is down, without restarting the pod.

Choosing the right handler

httpGet is appropriate for any HTTP service. It is the easiest to implement correctly: add a /healthz endpoint that returns 200 when the app is ready.

exec is best for non-HTTP workloads like message consumers, databases, or batch jobs. The command must exit 0 for success and non-zero for failure. Keep exec probe commands fast — they run synchronously on periodSeconds.

tcpSocket checks that a port accepts connections without understanding the application protocol. Useful for services where you can’t easily add an HTTP health endpoint.

grpc uses the standard gRPC health check protocol (grpc.health.v1.Health/Check). Requires the app to implement the protocol.

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.