Health Checks vs Readiness Checks — What to Expose on /actuator/health
Fast recall
Quick revision
Core answer
/actuator/health/liveness and /actuator/health/readiness.Whether the candidate understands the operational difference between liveness and readiness and the consequences of misconfiguring them.
Using the same endpoint for both liveness and readiness, causing a pod to be restarted when it is temporarily overloaded rather than just removed from the load balancer rotation.
Explain the startup probe as a third probe type in Kubernetes and how to use it with slow-starting Spring Boot applications to avoid false liveness failures on boot.
Interview-ready guide
Interview answer
Kubernetes uses two distinct health check types for different purposes — liveness checks determine if the process should be restarted; readiness checks determine if the pod should receive traffic. Confusing the two causes the most common Kubernetes availability issues.
Liveness vs readiness — the key distinction
- A liveness probe failure causes Kubernetes to restart the container — which means it should only fail if the application is in an unrecoverable state (deadlock, JVM OOM, corrupted state machine); if a transient dependency failure makes the liveness probe fail, Kubernetes restarts the pod, which doesn't fix the dependency and causes a restart loop
- A readiness probe failure removes the pod from the load balancer's backend pool — which means the pod is still running but receives no traffic; it recovers when the dependency becomes available, and Kubernetes adds it back to rotation automatically
Spring Boot Actuator configuration
- Spring Boot 2.3+ exposes
/actuator/health/livenessand/actuator/health/readinessseparately; configuremanagement.health.probes.enabled=trueto enable them - Liveness:
LivenessStateHealthIndicatorreportsCORRECT(healthy) orBROKEN(restart needed); database connectivity should NOT be in the liveness group - Readiness:
ReadinessStateHealthIndicatorplus any custom indicators for dependencies that affect traffic serving ability; database and downstream service health belong here
Database in the readiness probe
- Put database connectivity in the readiness probe, not the liveness probe — if the database is temporarily unavailable, the pod should stop receiving traffic (readiness fails), but not restart (liveness should still pass)
- When the database recovers, the readiness probe succeeds and the pod re-enters rotation; restarting the pod doesn't fix a database outage and causes unnecessary restarts
Custom health indicators
@Component class OrderServiceHealthIndicator implements HealthIndicator { public Health health() { ... } }adds a custom health check that appears in/actuator/healthand can be assigned to the readiness group
Health Checks vs Readiness Checks — What to Expose on /actuator/health
Direct Answer
Health checks report whether the application is alive (used by process supervisors to decide whether to restart). Readiness checks report whether the application is ready to receive traffic (used by load balancers and Kubernetes to decide whether to send requests). Spring Boot 2.3+ separates these into /actuator/health/liveness and /actuator/health/readiness.
Common Mistakes & Pitfalls
Using the same endpoint for both liveness and readiness, causing a pod to be restarted when it is temporarily overloaded rather than just removed from the load balancer rotation.
Check your understanding
Answer these without looking back at the article.
- What is a startup probe and how does it differ from a liveness probe?
- How do you write a custom HealthIndicator in Spring Boot?
- What is the risk of including external dependency health in a liveness probe?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.