<p>I have deployed a next.js frontend server and an express.js backend server on a Kubernetes cluster, which issues automated health checks, currently on the root path ("/") on the two servers. </p>

<p>My question is, should I implement my own health check routes like "<code>/health</code>" and just return a 200 HTTP response code on that route or should I just let it be as it is right now?</p>

<p>I'm afraid that I will implement a lot of functionality on the root path ("/") endpoint on both servers, which would put a bit more pressure on my two servers, as the cluster continues to issue requests to those endpoints.</p>

Axedyson
<p>Actually, if you are concerned about affecting the performance of your application, from the compute/memory resources perspective it depends on what material you are serving under <code>/</code>.</p>

<p>If you are serving a big blob of HTML it will actually affect your performance and I'd recommend implementing a different endpoint <code>/health</code> for healthcheck to be used with Kubernetes <a href="https://prometheus.io/" rel="nofollow noreferrer">Readiness Probes</a> for example.</p>

<p>If the content of <code>/</code> is very light, it's unlikely that it will make a difference. In terms of improving the 'stress' you are putting on the resources when running a healthcheck using Liveness/Readiness probes in K8s, you could alleviate that by increasing the <a href="https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes" rel="nofollow noreferrer"><code>periodSeconds</code></a> in them, but keep in mind that if you have multiple pods behind a <a href="https://kubernetes.io/docs/concepts/services-networking/service/" rel="nofollow noreferrer">Kubernetes service</a> and one of the pods has some issue with the healthcheck it would take longer for that pod to be removed from the service causing a longer potential 'downtime'.</p>
