<p>I'm building a few Spring Boot microservices that are getting deployed in a Kubernetes (AKS specifically) cluster. I was planning on setting the probePaths for the <strong><em>liveness &amp; readiness</em></strong> check to both point at the actuator health endpoint, but was wondering if that may not be the best option. My original thinking was that checking the path would be useful (at least for readiness) so that traffic wouldn't be sent to it until Spring has started up and is capable of handling requests. Since these services use a database connection, and the actuator health indicator will report status as down if it can't make a connection, will that not be such a good idea?</p>

<p>With liveness, I'm thinking it might start recycling the pods/containers over and over even though (in the case the DB is down) it might not fix anything.</p>

<p>With readiness, I'm thinking it might cause the pool of available apps to be 0 if the DB is down. The app itself will most likely not be very useful if the DB is down, but parts may still work potentially I suppose.</p>

<p>Is there a recommended best practice for this type of thing?</p>

<p>As of Spring Boot 2.3, <a href="https://docs.spring.io/spring-boot/docs/2.3.0.RELEASE/reference/html/spring-boot-features.html#boot-features-application-availability" rel="noreferrer">the Availability state of the application</a> (including Liveness and Readiness) is supported in the core and <a href="https://docs.spring.io/spring-boot/docs/2.3.0.RELEASE/reference/html/production-ready-features.html#production-ready-kubernetes-probes" rel="noreferrer">can be exposed as Kubernetes Probes with Actuator</a>.</p>

<p>Your question is spot on and this was discussed at length in <a href="https://github.com/spring-projects/spring-boot/issues/19593#issuecomment-572975767" rel="noreferrer">the Spring Boot issue for the Liveness/Readiness feature</a>.</p>

<p>The <code>/health</code> endpoint was never really designed to expose the application state and drive how the cloud platform treats the app instance it and routes traffic to it. It's been used that way quite a lot since Spring Boot didn't have better to offer here.</p>

<p>The <code>Liveness</code> should only fail when the internal state of the application is broken and we cannot recover from it. As you've underlined in your question, failing here as soon as an external system is unavailable can be dangerous: the platform might recycle all application instances depending on that external system (maybe all of them?) and cause cascading failures, since other systems might be depending on that application as well.</p>

<p>By default, the liveness proble will reply with "Success" unless the application itself changed that internal state.</p>

<p>The <code>Readiness</code> probe is really about the ability for the application to serve traffic. As you've mentioned, some health checks might show the state of essential parts of the application, some others not. Spring Boot will synchronize the Readiness state with the lifecycle of the application (the web app has started, the graceful shutdown has been requested and we shouldn't route traffic anymore, etc). There is a way to configure a "readiness" health group to contain a custom set of health checks for your particular use case.</p>

<p>I disagree with a few statements in the answer that received the bounty, especially because a lot changed in Spring Boot since:</p>

<ol>
<li>You should not use <code>/actuator/health</code> for Liveness or Readiness probes as of Spring Boot 2.3.0.</li>
<li>With the new Spring Boot lifecycle, you should move all the long-running startup tasks as <code>ApplicationRunner</code> beans - they will be executed after Liveness is Success, but before Readiness is Success. If the application startup is still too slow for the configured probes, you should then use the StartupProbe with a longer timeout and point it to the Liveness endpoint.</li>
<li>Using the management port can be dangerous, since it's using a separate web infrastructure. For example, the probes exposed on the management port might be OK but the main connector (serving the actual traffic to clients) might be overwhelmed and cannot serve more traffic. Reusing the same server and web infrastructure for the probes can be safer in some case. </li>
</ol>

<p>For more information about this new feature, you can read the dedicated <a href="https://spring.io/blog/2020/03/25/liveness-and-readiness-probes-with-spring-boot" rel="noreferrer">Kubernetes Liveness and Readiness Probes with Spring Boot</a> blog post.</p>
