Skip to content

Health Check Endpoints — Complete API Health Monitoring Guide

DodaTech Updated 2026-06-28 2 min read

In this tutorial, you will learn about Health Check Endpoints. We cover key concepts, practical examples, and best practices to help you master this topic.

Health check endpoints are lightweight HTTP endpoints that indicate whether your API is healthy. They are used by load balancers, Kubernetes, and monitoring systems to detect failures.

What You'll Learn

You'll learn how to implement health check endpoints, what to check, and how to structure responses.

Why It Matters

Orchestrators like Kubernetes rely on health checks to restart unhealthy containers. Load balancers use them to stop sending traffic to failing instances.

Real-World Use

Kubernetes uses liveness probes (is the app alive?) and readiness probes (is the app ready for traffic?). If a health check fails 3 times, Kubernetes restarts the pod.

Implementation

from flask import Flask, jsonify
import redis
import psycopg2

app = Flask(__name__)

def check_database():
    try:
        conn = psycopg2.connect("dbname=test user=postgres", connect_timeout=2)
        conn.close()
        return True
    except Exception:
        return False

def check_redis():
    try:
        r = redis.Redis(host="localhost", port=6379, socket_connect_timeout=2)
        r.ping()
        return True
    except Exception:
        return False

@app.route("/healthz")
def liveness():
    return jsonify({"status": "ok"}), 200

@app.route("/readyz")
def readiness():
    deps = {
        "database": check_database(),
        "redis": check_redis()
    }
    all_healthy = all(deps.values())
    if all_healthy:
        return jsonify({"status": "ok", "checks": deps}), 200
    return jsonify({"status": "degraded", "checks": deps}), 503

Common Patterns

Pattern Description Status
/healthz (liveness) Is app running? 200 OK or die
/readyz (readiness) Can app accept traffic? 200 or 503
/startupz Has app finished initialization? 200 or 503
/health Combined check JSON with dependency status

Common Mistakes

| Mistake | Fix | |---------|-----| | Heavy health checks | Overload databases with every probe | Keep checks lightweight (ping, not queries) | | No timeout on dependency checks | Health check hangs | Set short connect timeouts (2-5 seconds) | | Including auth on health endpoint | Monitoring tools blocked | Keep health endpoints public | | Not distinguishing liveness vs readiness | Restart on transient DB failure | Liveness: Process alive; Readiness: dependencies ok | | No startup delay | App restarts before ready | Use startup probe for initialization |

Practice Questions

  1. What is the difference between liveness and readiness?
  2. Why should health checks have timeouts?
  3. What dependencies should you check in readiness?
  4. Why should health endpoints be unauthenticated?
  5. How do you handle health checks in Kubernetes?

Challenge

Implement health endpoints with database and Redis checks. Deploy with Docker and configure Kubernetes liveness and readiness probes. Test by stopping Redis.

What's Next

Learn about Prometheus metrics for API monitoring.

Built by the developers of DodaTech

Doda Browser, DodaZIP & Durga Antivirus Pro