Verificações de integridade e reinicializações

A deployed server can hang or crash silently. A health check is a simple probe that answers the question: are you still alive? 🩺

The classic pattern is a tiny route, often /health, that returns 200 OK when the server is ready to handle work.

A health check runs constantly, so keep it lightweight. It should confirm the process responds without doing heavy real work.

Two ideas matter: liveness asks is the process alive, while readiness asks is it ready to accept traffic yet. They can differ at startup.

Docker can run a HEALTHCHECK on a schedule. If the command fails enough times, the container is marked unhealthy.

A restart policy tells the platform to bring a dead container back automatically, so a single crash does not mean downtime.

Tools like Kubernetes use the same probes to restart unhealthy pods and to route traffic only to ready instances.

If a server crashes instantly on boot, blind restarts just loop forever. Use backoff so retries slow down and you can see the real error.

A deep readiness check can ping a database, but be careful: if every server marks itself unready at once, an outage can cascade.

On shutdown, stop accepting new calls but let in-flight ones finish. This graceful drain prevents cutting clients off mid-request.

Health checks plus restart policies give you a self-healing service that recovers from most failures with no human awake at 3am. 🌙

What is the difference between a liveness and a readiness check?

A cheap /health endpoint plus a restart policy makes your server self-healing: probes catch failures and the platform brings it back. 💪