intermediate

Health checks

Expose machine-readable endpoints that report whether a service can handle traffic and its critical dependencies.

Health checks are machine-readable endpoints or commands used by load balancers, orchestrators, and monitoring. They should answer whether the service can safely receive traffic — not merely whether a process exists.

| Check kind | Question | |------------|----------| | Liveness | Is the process stuck and need restart? | | Readiness | Should this instance receive traffic now? | | Startup | Has slow initialization finished? | | Deep / synthetic | Can a user-critical path succeed end to end? |

					app.get('/health/ready', async (_req, res) => {
  await db.ping();
  res.status(200).json({ status: 'ready' });
});
				

Keep checks fast, idempotent, and bounded. Avoid depending on every downstream in liveness probes.

On interviews: shallow vs dependency checks, startup vs readiness vs liveness, and user-impacting synthetic monitoring.

Common pitfalls: always-200 endpoints hide outages; deep dependency checks cause cascading restarts.

The trade-off is check thoroughness versus speed and blast radius when dependencies flap.

Checklist:

  • Define what healthy means per surface.
  • Keep checks fast and bounded.
  • Avoid cascading dependency failure in liveness.
  • Separate readiness from liveness semantics.