Stop 19 · Monitoring & LoggingTopics · 5/9

Health Check Endpoints

In short

Load balancers, Kubernetes and uptime tools all ask one question: is this instance OK? A tiny /health route answers it, and decides whether you get traffic or a restart.

A simple `/health` endpoint that reports whether your service (and its dependencies like the database) is up and working — used by load balancers and orchestrators to know if an instance should receive traffic.

The purple blob takes morning attendance as a row of small students raise their hands.

Think of it like this

Morning roll call

The teacher calls each name and waits for 'present'. Silence means absent, and that seat gets no work today. Health checks are roll call for servers: the load balancer calls /health, and an instance that doesn't answer stops getting requests.

Watch it happen

Liveness vs readiness

Load balancer

App

Postgres

GET /health/live

1/6Liveness: is the process alive and responding? No database checks, just a quick 200.

The big ideas

What you need to know

Liveness vs readiness

Liveness asks 'should I restart you?'. Readiness asks 'should I send you traffic?'. Different questions, different checks.

Fast and cheap

Checks run every few seconds. Keep them light, with short timeouts, and never run heavy queries.

Don't leak details

Return a simple status publicly. Detailed dependency info can sit behind auth or an internal port.

Graceful shutdown

On SIGTERM, start failing readiness, finish in-flight requests, then exit, so no request is cut off.

See it in code

Walk through the code

1app.get("/health/live", (_req, res) => res.status(200).send("ok"));2 3app.get("/health/ready", async (_req, res) => {4  try {5    await Promise.race([6      db.query("SELECT 1"),7      new Promise((_, reject) => setTimeout(() => reject(new Error("timeout")), 1000)),8    ]);9    res.status(200).json({ status: "ready" });10  } catch {11    res.status(503).json({ status: "not ready" });12  }13});

1/4Liveness does no I/O. If the process can answer this, it's alive.

Point Kubernetes livenessProbe at /health/live and readinessProbe at /health/ready. Load balancers usually use the readiness one.

Save yourself the pain

Common mistakes

Oops

Making the liveness check query the database.

Do this instead

If the DB blips, every instance gets restarted at once and things get worse. Check dependencies in readiness only.

Oops

Returning 200 from /health no matter what.

Do this instead

Then traffic keeps flowing to a broken instance. The check must reflect whether you can really serve.

Your mission

Add real health checks

~25 min

Quick check

The database goes down for 30 seconds. What should happen to your API instances?

Go deeper

1Add a `/health` endpoint that checks database connectivity, not just that the process is running.
2Learn the difference between liveness checks (is it running) and readiness checks (is it ready for traffic).
3Understand how orchestrators like Kubernetes use these to automatically restart unhealthy instances.