Health Check Endpoint

The implementation:

func healthHandler(w http.ResponseWriter, r *http.Request) {
    // Liveness: the process is up — 200 always (unless crashing)
    w.Header().Set("Content-Type", "application/json")
    w.WriteHeader(http.StatusOK)
    json.NewEncoder(w).Encode(map[string]string{"status": "ok"})
}

// The deep version — checks dependencies:
func readinessHandler(db *sql.DB) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        if err := db.PingContext(r.Context()); err != nil {
            // The DB is down — I'm running but can't serve
            w.WriteHeader(http.StatusServiceUnavailable)
            json.NewEncoder(w).Encode(map[string]string{"status": "unhealthy"})
            return
        }
        w.WriteHeader(http.StatusOK)
        json.NewEncoder(w).Encode(map[string]string{"status": "ready"})
    }
}

mux.HandleFunc("/healthz", healthHandler)          // liveness
mux.HandleFunc("/readyz", readinessHandler(db))    // readiness

The two types (the Kubernetes semantics — the industry vocabulary):

• LIVENESS (/healthz): 'is the process alive?' — 200 while running. If it fails, the orchestrator RESTARTS the container (the process is wedged).
• READINESS (/readyz): 'can I serve traffic?' — 200 when dependencies (DB, downstream) are reachable. If it fails, the load balancer STOPS ROUTING to me (but doesn't restart).

The distinction's purpose: a DB outage with a failing readiness (routes stop, service removed from LB, no restarts — DB recovers, routes return). If readiness were liveness, every DB blip would RESTART every pod — the cascade.

The instrumentation rules: the health check is the ONE endpoint that must never touch the DB (the liveness version) — a DB-connected liveness is the self-inflicted outage. The readiness CAN check dependencies (that's its job) — with a timeout (the dependency check must not hang).