Liveness, Readiness, Startup Probe Comparison

Liveness Probe #

Checks if the container is alive (e.g., for deadlocks, hangs).

If it fails, the container is restarted. It's used to check for situations where the process is alive but unrecoverable, such as GC thrashing, deadlocks, or infinite waits.

Upon failure, it immediately restarts the container and is unrelated to traffic blocking.

livenessProbe:
  httpGet:
    path: /health/live
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10

Readiness Probe #

Determines if the container is ready to receive traffic.

If it fails, the pod remains alive but is removed from the service endpoint. It does not restart the pod.

Used to check for external dependency failures, circuit open states, or completion of warm-up.

Its characteristic is that it's for traffic blocking and is the most frequently used.

readinessProbe:
  httpGet:
    path: /health/ready
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5

Startup Probe #

Determines if the startup process has completed. Also used to protect slow-starting applications.

If it fails, it disables liveness and readiness probes until startup is complete. If startup failures accumulate, the container is restarted.

When to use it: Spring Boot startup, migrations, cache loading, class loading, etc.

Its characteristic is that it declares that the container's liveness should not be checked yet, and it's exclusively for the initial startup phase.

startupProbe:
  httpGet:
    path: /health/startup
    port: 8080
  failureThreshold: 30
  periodSeconds: 5

The example above allows for a total startup time of 150 seconds (30 failures * 5 seconds/period).

It's recommended to manage startup with a separate controller, and then activate only readiness and liveness probes, controlling their return based on a startup completion flag.