skip to content

What is the difference between the liveness and readiness probes exposed by Spring Boot Actuator, and what does Kubernetes do with each?

level: juniorimportance: must knowfreq 70%

answer

  1. liveness -> restart pod
  2. readiness -> pull from load balancer
  3. two health groups auto-added under Kubernetes
  4. never put DB check in liveness (restart storm)
  5. LivenessState vs ReadinessState

basics

~20 s

Liveness says the app is running and healthy; if it fails, Kubernetes restarts the pod. Readiness says the app can accept traffic right now; if it fails, Kubernetes stops routing requests to it but does not restart.

solid answer

~40 s

Spring Boot Actuator auto-exposes two probe endpoints when it detects Kubernetes (or when you enable them): '/actuator/health/liveness' and '/actuator/health/readiness'. Liveness reflects whether the application's internal state is intact — a broken liveness means the app is in an unrecoverable state, so Kubernetes kills and restarts the pod. Readiness reflects whether the app is ready to handle traffic — startup finished, warm-up done, not overloaded or gracefully shutting down. A failing readiness makes Kubernetes remove the pod from Service endpoints so it stops receiving requests, without restarting it. The key distinction: liveness failure is fatal and triggers a restart; readiness failure is temporary and only affects traffic routing. Both are backed by Spring's ApplicationAvailability state (LivenessState and ReadinessState), not by arbitrary health indicators.

code

yaml · 17 lines
yaml
# application.yml — force probes on outside Kubernetes too
management:
  endpoint:
    health:
      probes:
        enabled: true
      show-details: always

# Kubernetes Deployment snippet
# livenessProbe:
#   httpGet:
#     path: /actuator/health/liveness
#     port: 8080
# readinessProbe:
#   httpGet:
#     path: /actuator/health/readiness
#     port: 8080

go deeper

for a junior

Know the one-line distinction: liveness->restart, readiness->traffic routing, and the two endpoint paths.

for a middle

Explain the backing states and why liveness must not depend on external systems (restart storm).

for a senior

Discuss auto-detection of the Kubernetes platform, enabling probes explicitly, and graceful-shutdown readiness flip.

for a principal

Reason about failure-mode blast radius: correlated liveness failures vs isolated readiness removal, and platform-wide probe conventions.

## Background: what a probe is Kubernetes periodically calls HTTP endpoints on your pod to decide its fate. A **liveness probe** answers 'is this process still healthy, or is it wedged and should be restarted?' A **readiness probe** answers 'should this pod receive traffic right now?' ## What Spring Boot provides Spring Boot Actuator ships built-in support for these via two **health groups**: - `/actuator/health/liveness` — backed by `LivenessState` - `/actuator/health/readiness` — backed by `ReadinessState` These are auto-configured (the endpoints appear) when Spring detects it is running in Kubernetes — specifically when the `spring.main.cloud-platform` is resolved to `KUBERNETES` (detected from env vars like `KUBERNETES_SERVICE_HOST`). You can force them on anywhere with: ``` management.endpoint.health.probes.enabled=true ``` ## The semantic difference (the core of the question) | | Liveness | Readiness | |---|---|---| | Question answered | Is the app's internal state broken beyond recovery? | Can the app serve traffic now? | | Failure means | Restart the pod | Remove pod from Service load-balancer | | Recovery | Requires restart | Recovers on its own when state flips back | | Backing state | `LivenessState` (`CORRECT` / `BROKEN`) | `ReadinessState` (`ACCEPTING_TRAFFIC` / `REFUSING_TRAFFIC`) | ## Gotchas - **Don't put slow external dependency checks in liveness.** If your database is momentarily down and your liveness probe fails because of it, Kubernetes will restart every pod — a restart storm that fixes nothing. Dependency health belongs in readiness (or a separate concern), not liveness. Spring deliberately keeps `LivenessState` decoupled from external systems for this reason. - Liveness should almost never depend on anything external; it should only go `BROKEN` when the app itself is in an unrecoverable internal state. - Readiness automatically goes to `REFUSING_TRAFFIC` during graceful shutdown so in-flight requests drain while new ones stop arriving. ## When to use Always configure both in any Kubernetes deployment. Map them in your Deployment manifest to `livenessProbe.httpGet.path: /actuator/health/liveness` and `readinessProbe.httpGet.path: /actuator/health/readiness`.

  • Why is it dangerous to include a database connectivity check in the liveness probe?
    If the DB briefly goes down, every pod's liveness fails and Kubernetes restarts all of them simultaneously — a restart storm that doesn't fix the DB and can make recovery worse. DB availability belongs in readiness, which only pulls the pod out of the load balancer.
  • What are the actual endpoint paths, and when do they appear automatically?
    '/actuator/health/liveness' and '/actuator/health/readiness'. They appear automatically when Spring detects the Kubernetes cloud platform (spring.main.cloud-platform=KUBERNETES), or when you set management.endpoint.health.probes.enabled=true anywhere.

saying these in an interview costs you the question

  • Saying a failing readiness probe restarts the pod (it only removes it from the load balancer)
  • Saying liveness should check the database or downstream services
  • Claiming you must write custom HealthIndicators to get probes (they're auto-configured)
  • Confusing the two: putting readiness-style traffic logic into liveness

context

resolving links…