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.