Probes that mean something

Most tutorials end health checks at /health returning 200 OK. Orchestrators like Kubernetes, ECS, and Docker want two different signals. Liveness asks, is the process alive? Readiness asks, can it serve traffic right now? Mixing them up is how you end up with pods that restart forever or pods that serve traffic before they are ready.

What the orchestrator does with each probe

Liveness controls restarts. Readiness controls traffic.

router.py

python

@router.get("/health/live")
async def liveness():
    """
    Liveness: is the process alive and responsive?
    Must be cheap (no external calls). Container orchestrators restart
    the pod if this fails.
    """
    return {"status": "alive"}

Liveness returns true as long as the event loop is running. No database call, no LLM ping, no disk read. If liveness starts doing heavyweight checks, a slow dependency can trigger restarts you never wanted.

Because liveness failing tells the orchestrator to restart the container. If your database has a five minute outage and your liveness probe calls it, every pod in the cluster restarts, piles onto the recovering database, and you get a thundering herd. Liveness only dies if the process itself is wedged.

Quiz: Quiz

Loading practice…