Kubernetes Probes: Liveness vs Readiness vs Startup for Spring Boot

Intermediate·3 min read·

Fast recall

Quick revision

Core answer

Liveness answers 'is the process stuck?' — failure restarts the container. Readiness answers 'can this pod serve traffic now?' — failure removes it from Service endpoints without restart. Startup answers 'has the app finished initializing?' — while failing, both liveness and readiness are suspended. Use all three for Spring Boot: startup covers slow boot, readiness tracks dependency health, liveness catches only unrecoverable deadlocks.

Interview Answer3 min

Kubernetes uses three probe types to determine container health, and they exist for different failure modes. Misconfiguring them — particularly confusing liveness with readiness — causes either cascading restarts that bring down a healthy application or traffic being sent to containers that are not ready.

Liveness — is the JVM responding?

A failed liveness check restarts the container; it is the circuit breaker for deadlocked, hung, or permanently broken processes that cannot recover without a restart.
Use the Actuator liveness endpoint: GET /actuator/health/liveness — Spring Boot 2.3+ reports UP when the context is healthy and not broken; it does not check database connectivity because a database outage should not restart healthy Pods.
Set a generous window via startup probe rather than initialDelaySeconds — a liveness probe that fires during Spring Boot's init triggers a restart loop.

Readiness — is the app ready for traffic?

A failed readiness check removes the Pod from the Service's Endpoints; traffic stops routing to it, but the Pod keeps running and can recover; this is the correct response to temporary overload or slow downstream dependencies.
Use GET /actuator/health/readiness — Spring Boot's readiness state starts as REFUSING_TRAFFIC during init and transitions to ACCEPTING_TRAFFIC only after ApplicationReadyEvent fires, including database connection pool establishment.
Set readiness failureThreshold lower than liveness — failing quickly removes a pod from rotation; liveness requires more failures before triggering restart to avoid restarting a slow-but-recovering pod.

Startup — protecting slow-starting JVMs

The startup probe is the correct solution for slow Spring Boot apps; while it has not succeeded, liveness and readiness checks are suspended — this prevents the restart loop during initialization.
failureThreshold: 30 with periodSeconds: 10 gives the app 5 minutes to start; after startup succeeds, liveness and readiness take over with normal thresholds.
Without a startup probe you must inflate liveness initialDelaySeconds — that delay also applies after real restarts, making recovery slower than necessary.

Anti-patterns to avoid

Dependency checks in liveness turn a partial outage into a total one — a 30-second DB failover restarts every pod across every replica simultaneously.
Exec probes on memory-tight JVM pods are expensive — they fork processes inside the container; prefer HTTP probes unless you must shell out.

Interview-ready guide

Interview answer

Liveness — is the JVM responding?

A failed liveness check restarts the container; it is the circuit breaker for deadlocked, hung, or permanently broken processes that cannot recover without a restart.
Use the Actuator liveness endpoint: GET /actuator/health/liveness — Spring Boot 2.3+ reports UP when the context is healthy and not broken; it does not check database connectivity because a database outage should not restart healthy Pods.
Set a generous window via startup probe rather than initialDelaySeconds — a liveness probe that fires during Spring Boot's init triggers a restart loop.

Readiness — is the app ready for traffic?

A failed readiness check removes the Pod from the Service's Endpoints; traffic stops routing to it, but the Pod keeps running and can recover; this is the correct response to temporary overload or slow downstream dependencies.
Use GET /actuator/health/readiness — Spring Boot's readiness state starts as REFUSING_TRAFFIC during init and transitions to ACCEPTING_TRAFFIC only after ApplicationReadyEvent fires, including database connection pool establishment.
Set readiness failureThreshold lower than liveness — failing quickly removes a pod from rotation; liveness requires more failures before triggering restart to avoid restarting a slow-but-recovering pod.

Startup — protecting slow-starting JVMs

The startup probe is the correct solution for slow Spring Boot apps; while it has not succeeded, liveness and readiness checks are suspended — this prevents the restart loop during initialization.
failureThreshold: 30 with periodSeconds: 10 gives the app 5 minutes to start; after startup succeeds, liveness and readiness take over with normal thresholds.
Without a startup probe you must inflate liveness initialDelaySeconds — that delay also applies after real restarts, making recovery slower than necessary.

Anti-patterns to avoid

Dependency checks in liveness turn a partial outage into a total one — a 30-second DB failover restarts every pod across every replica simultaneously.
Exec probes on memory-tight JVM pods are expensive — they fork processes inside the container; prefer HTTP probes unless you must shell out.

03 · Deep dive