Intermediate
Open
Free
Health Check Design
Design a /health endpoint for a FastAPI service that:
- Returns
200 OKwhen the service is ready to handle traffic. - Returns a non-200 status when it is not ready (e.g., during startup, database is unreachable, or graceful shutdown is in progress).
What should the health check verify? What should it NOT check?
Solution
What to verify (liveness + readiness):
- Database connectivity: attempt a cheap query (e.g.,
SELECT 1) against the primary database. If it fails, the service cannot serve most requests. - Cache connectivity (optional): ping Redis. If Redis is down, session-based routes will fail.
- Any other critical dependency without which the service cannot function.
What NOT to check:
- External third-party APIs (Stripe, Cognito, email) — these are not the service's responsibility. A Stripe outage should not mark your service as unhealthy (your health endpoints will trigger unnecessary failovers).
- Background jobs or queue depth — these do not block request handling.
- Expensive queries — a health check that takes 500 ms degrades service under load (the load balancer calls it frequently).
Graceful shutdown:
When a SIGTERM is received (before the process exits), set an in-process
flag that causes /health to return 503 Service Unavailable. The load
balancer stops routing new requests to this instance. Existing in-flight
requests continue to completion before the process exits.
Example response:
{"status": "ok", "db": "ok", "redis": "ok"}