Kubernetes has a core point in its philosophy: an application should not have to behave differently in a cluster. The readiness and liveness probes are generally useful outside k8s, so it doesn't really make sense (to me) that I have to set an explicit property to see them running locally.

Comment From: bclozel

That was the plan! But unfortunately we can't do that before Spring Boot 3.x, see this comment.

Comment From: dsyer

That was a comment about graceful shutdown. Did you link to the wrong place?

Comment From: bclozel

I don't think so. I'm reproducing and updating the comment here still:

The LivenessProbeHealthIndicator and ReadinessProbeHealthIndicator, unlike other health indicators, are not enabled by default. Same thing goes for the "liveness" and "readiness" Health Groups. They're generally useful, but right now they're only enabled if the management.endpoint.health.probes.enabled=true or if k8s is detected.

If we did enable those by default, here's what would happen:

  • the LivenessProbeHealthIndicator and ReadinessProbeHealthIndicator would show up in the default group in /actuator/health. Many platforms look at this endpoint to figure out if an application is healthy or not. During startup time (and especially with long-running ApplicationRunner tasks), the readiness probe will report OUT_OF_SERVICE which could trick platforms into restarting the app indefinitely if the configured timeout is too short. In short, we're adding new facets to application availability and this is a major change that can create issues during the upgrade...
  • we could enable those health indicators but not take them into account in the default /actuator/health group. In this case, we'd have an inconsistent state (a specific group could report as broken, but the default group still reports "all fine").

We'd like to switch this default but we'll need to do that for our next major version and guide developers when it comes to configuring health/availability checks on their platforms.

Comment From: ThomasVitale

@bclozel is this issue still considered for a 3.x version?