Stage 3 · Build
Production-Ready Services
Health Checks
Expose liveness and readiness endpoints that check database, Redis, queue, and dependency status.
7 min readBuilding Backend ApplicationsBuild
Why Health Checks
Kubernetes, load balancers, and orchestrators need to know if your service is alive and ready to serve traffic. Health check endpoints provide this signal. Without them, traffic routes to broken instances.
Liveness vs Readiness
| Type | Purpose | Action on Failure |
|---|---|---|
| Liveness | Is the process alive? | Restart the container |
| Readiness | Can it serve traffic? | Remove from load balancer |
| Startup | Has initialization completed? | Wait before checking liveness |
Dependency Checks
Gochecking-dependencies.go
25 linesLn 1, Col 1Go
Check each critical dependency. Return the status of each one. This helps operators identify which dependency is causing problems.
Health Handler
Gohealth-check-http-handler.go
36 linesLn 1, Col 1Go
Liveness checks should be lightweight — just verify the process is alive. Readiness checks verify dependencies. Deep checks verify every dependency in detail.
Deep Health Checks
Godetailed-dependency-status.go
30 linesLn 1, Col 1Go
Deep health checks include version information, latency for each dependency, and detailed error messages. Use these for debugging, not for liveness probes.
Monitoring
- Kubernetes livenessProbe: HTTP GET /healthz every 10s.
- Kubernetes readinessProbe: HTTP GET /readyz every 5s.
- Load balancer: Health check endpoint for target registration.
- Monitoring: Alert when health checks fail for > 1 minute.
Keep liveness checks simple
Liveness checks should never call external services. If the database is down, the process is still alive. Only restart on deadlocks, out-of-memory, or unrecoverable errors.
Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.