Key Health Checks Every Production Java App Should Have
Fast recall
Quick revision
Core answer
Whether you distinguish between liveness (is the process alive?), readiness (is it ready for traffic?), and startup (is it still initializing?) probes, and can design meaningful health checks beyond just returning 200 OK.
Implementing a health endpoint that always returns 200 regardless of dependencies, making it useless for load balancer traffic management.
Mention Spring Boot Actuator's built-in health indicators, how to add custom health indicators for business-critical dependencies, and the risk of cascading health check failures causing stampedes.
Interview-ready guide
Interview answer
Every production Java application needs three types of health checks serving three different consumers: Kubernetes liveness (should this pod be restarted?), Kubernetes readiness (should this pod receive traffic?), and monitoring dashboards (what's the overall service health?).
Liveness — process health
- The liveness probe should return healthy as long as the JVM process is not deadlocked or in an unrecoverable state — it should not check database connectivity, downstream service availability, or any external dependency
- A liveness probe that checks the database will fail when the database is temporarily unavailable, causing Kubernetes to restart healthy pods — which doesn't fix the database and causes a restart loop that amplifies the incident
/actuator/health/livenesswith Spring Boot'sLivenessStateHealthIndicatorreports the Spring application lifecycle state; it fails only when the application itself signals it's in a broken state
Readiness — traffic acceptance
- The readiness probe checks everything the application needs to serve traffic — database connectivity, critical downstream service availability, message broker connectivity, application initialization complete
- When readiness fails, Kubernetes removes the pod from the load balancer's target group; when it recovers, the pod re-enters rotation automatically; this is the correct behavior for transient dependency outages
/actuator/health/readinessincludes all beans in the readiness group; add customHealthIndicatorbeans for critical dependencies
Startup probe — for slow-starting applications
- Spring Boot's ApplicationContext initialization (component scanning, auto-configuration, database connection pool warming) takes 5-30 seconds; a liveness probe that starts checking too early fails and kills a healthy pod
- Configure a
startupProbewith a longfailureThreshold x periodSeconds(e.g., 30 x 5 = 150 seconds) that gives Spring Boot time to start; after the startup probe passes, liveness and readiness take over
Monitoring health
- The full
/actuator/healthendpoint includes all indicators — database, disk space, queue connectivity, downstream services — and is used by monitoring dashboards and health check UIs, not Kubernetes probes; it provides detailed status for operational visibility
Key Health Checks Every Production Java App Should Have
Direct Answer
Every production Java app needs liveness (process health), readiness (traffic acceptance), startup (initialization), and deep health checks covering database, cache, and critical upstream dependencies.
Common Mistakes & Pitfalls
Implementing a health endpoint that always returns 200 regardless of dependencies, making it useless for load balancer traffic management.
Check your understanding
Answer these without looking back at the article.
- How do you prevent health check cascades in a microservices system?
- What is the difference between liveness and readiness probes in Kubernetes?
- How do you expose custom health indicators in Spring Boot Actuator?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.