Liveness asks whether a process needs replacement; readiness asks whether it should receive new traffic.
Spring Boot liveness versus readiness: do not restart on every dependency outage
The two paths diverge
In the checked local server, importStore becomes DOWN. Readiness returns 503 while liveness still returns 200. That is intentional: a store outage can make new import work unsafe without proving that restarting this JVM will repair the store. The test also checks that anonymous API access remains 401, so probe exposure does not open business routes.
Spring Boot's health groups supply distinct endpoint paths when probes are enabled. The custom importStore indicator is included only in readiness for this test. The group lesson shows the property wiring. The earlier indicator lesson checks UP/DOWN directly but does not establish HTTP behavior.
Plan termination and recovery
When readiness fails, an orchestrator may stop sending new traffic, but in-flight work, drain time and queued jobs need their own policy. A bad liveness rule can create a restart loop across the fleet during a shared dependency failure. Set probe thresholds and timeouts from measured startup and recovery behavior. This fixture tests one instance at one point in time; no rolling deployment or restart policy is checked.
Checked source
assertEquals(503, get("/actuator/health/readiness").statusCode());
assertEquals(200, get("/actuator/health/liveness").statusCode());
assertEquals(401, get("/api/receipts").statusCode());Verification boundary
ReadinessHealthGroupHttpTest.failedImportStoreWithdrawsReadinessWithoutChangingLiveness in the downloadable Spring source kit. The excerpt is shortened; the kit contains the complete test.
Costs and limits
The local indicator flips immediately and has no network timeout or stale cache. These assertions say nothing about Kubernetes probe periods, restart thresholds, startup probes or graceful drain. The extra HTTP requests are low cost in the fixture; measure real indicators before choosing intervals.
Common Mistakes
- Do not make a shared dependency outage a liveness failure by default.
- Do not assume readiness drains in-flight requests.
- Do not set probe thresholds without measuring startup and recovery.
Read next
Spring Boot readiness health group: withdraw traffic on a required dependency failure, Spring readiness: report an unavailable dependency without forcing liveness failure, Spring Boot Actuator health: public liveness without public diagnostics, Spring Security health probes: expose only the health path.
