skip to content

Kubernetes Liveness & Readiness Probes

4 roadmaps5 questions

Boot exposes liveness and readiness groups backed by application availability state, which your code can flip by publishing an availability event. Interviewers ask for the difference between the two probes: readiness removes traffic, liveness restarts the pod.

part ofSpring Frameworkoverview, primer and where to startread it →
on this pageshow

explore

questions

5

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…

open as a page

How do you programmatically flip the readiness (or liveness) probe to DOWN at runtime in Spring Boot?

level: seniorimportance: must knowfreq 50%

basics

~10 s

Publish an AvailabilityChangeEvent via the ApplicationEventPublisher, e.g. AvailabilityChangeEvent.publish(publisher, this, ReadinessState.REFUSING_TRAFFIC). Spring updates ApplicationAvailability and the probe endpoint immediately reflects the new state.

open as a page

How do you read the current liveness/readiness state programmatically in Spring Boot, and what are the possible state values?

level: middleimportance: should knowfreq 45%

basics

~10 s

Inject the ApplicationAvailability bean and call getLivenessState() or getReadinessState(). Liveness is CORRECT or BROKEN; readiness is ACCEPTING_TRAFFIC or REFUSING_TRAFFIC. Both implement the AvailabilityState interface.

open as a page

How do Spring Boot's availability states behave across the application lifecycle, and how does this interact with graceful shutdown in Kubernetes?

level: seniorimportance: should knowfreq 35%

basics

~20 s

At startup liveness becomes CORRECT early; readiness becomes ACCEPTING_TRAFFIC only when the app is fully ready. On shutdown Spring flips readiness to REFUSING_TRAFFIC so Kubernetes drains traffic before the process stops, which pairs with graceful shutdown.

open as a page

How are the liveness and readiness health groups composed, and how would you add your own health checks or a custom availability dimension into a probe group?

level: principalimportance: nice to knowfreq 20%

basics

~10 s

The probes are Actuator health groups: 'liveness' includes livenessState and 'readiness' includes readinessState. You can override group membership with management.endpoint.health.group.<name>.include to add other indicators, and set per-group status mappings and roles.

open as a page