Spring Boot readiness health group: withdraw traffic on a required dependency failure

The local HTTP result

The test starts ReceiptApplication on a random loopback port with probes enabled and a test-only importStore indicator included in the readiness group. When the AtomicBoolean-backed indicator is UP, /actuator/health/readiness returns 200. When it becomes DOWN, the same path returns 503. The liveness path remains 200, and the receipt API still rejects an anonymous request. This is a real local HTTP/filter-path check, unlike the earlier direct HealthIndicator unit test.

ReceiptSecurity now permits the health endpoint and its nested group paths without credentials. It does not permit the API. The liveness lesson explains why a dependency failure should not necessarily ask an orchestrator to restart the process. The exposure lesson covers the narrow public path.

Keep the health question narrow

The indicator in this test is not a real database or broker check. A production readiness component should measure the dependency required to accept new work, with a bounded timeout and no expensive query per probe. Include it in readiness only if the service cannot safely accept traffic without it. The app's default runtime configuration does not enable this test indicator or health group wiring; deployment configuration remains to be written.

Checked source

management.endpoint.health.probes.enabled=true
management.endpoint.health.group.readiness.include=readinessState,importStore

Verification boundary

ReadinessHealthGroupHttpTest.failedImportStoreWithdrawsReadinessWithoutChangingLiveness in the downloadable Spring source kit. The excerpt is shortened; the kit contains the complete test.

Costs and limits

One temporary Boot server and an AtomicBoolean indicator prove local HTTP status mapping. There is no Kubernetes object, load balancer, real dependency timeout or deployment drain test. Frequent expensive health checks can increase load during an outage; the fixture's boolean is constant time.

Common Mistakes

• Do not put every optional dependency into readiness.
• Do not call a test boolean a live database probe.
• Do not assume a local 503 has been wired to the orchestrator.

Read next

Spring Boot liveness versus readiness: do not restart on every dependency outage, Spring Security health probes: expose only the health path, Spring readiness: report an unavailable dependency without forcing liveness failure, Spring Boot Actuator health: public liveness without public diagnostics.

Release boundary continuation

Continue with Spring readiness during termination: stop routing before stopping dependencies.