<p>I am working on an application that, as I can see is doing multiple health checks?</p>
<ol>
<li>DB readiness probe</li>
<li>Another API dependency readiness probe</li>
</ol>
<p>When I look at cluster logs, I realize that my service, when it fails a DB-check, just throws 500 and goes down. What I am failing to understand here is that if DB was down or another API was down and IF I do not have a readiness probe then my container is going down anyway. Also, I will see that my application did throw some 500 because DB or another service was off.</p>
<p>What is the benefit of the readiness probe of my container was going down anyway? Another question I have is that is Healthcheck something that I should consider only if I am deploying my service to a cluster? If it was not a cluster microservice environment, would it increase/decrease benefits of performing healtheck?</p>

Lost
<p>There are three types of probes that Kubernetes uses to check the health of a <code>Pod</code>:</p>
<ul>
<li><code>Liveness</code>: Tells Kubernetes that something went wrong inside the container, and it's better to restart it to see if Kubernetes can resolve the error.</li>
<li><code>Readiness</code>: Tells Kubernetes that the <code>Pod</code> is ready to receive traffic. Sometimes something happens that doesn't wholly incapacitate the <code>Pod</code> but makes it impossible to fulfill the client's request. For example: losing connection to a database or a failure on a third party service. In this case, we don't want Kubernetes to reset the <code>Pod</code>, but we also don't wish for it to send it traffic that it can't fulfill. When a <code>Readiness</code> probe fails, Kubernetes removes the <code>Pod</code> from the service and stops communication with the <code>Pod</code>. Once the error is resolved, Kubernetes can add it back.</li>
<li><code>Startup</code>: Tells Kubernetes when a <code>Pod</code> has started and is ready to receive traffic. These probes are especially useful on applications that take a while to begin. While the <code>Pod</code> initiates, Kubernetes doesn't send <code>Liveness</code> or <code>Readiness</code> probes. If it did, they might interfere with the app startup.
You can get more information about how probes work on this link:</li>
</ul>
<p><a href="https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/" rel="nofollow noreferrer">https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/</a></p>
