Skip to content
AITroveRead. Build. Understand.
Make this comfortable

Spring Boot liveness versus readiness: do not restart on every dependency outage

Last updated: 30 Sept 20264 min read
tutorial
IntermediateBy AITrove Editorial

Liveness asks whether a process needs replacement; readiness asks whether it should receive new traffic.

Download Spring source kit

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

Java
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.

spring
spring-boot
liveness-readiness-separation
Storage details