Liveness Is Not Readiness

Different questions need different probes

A liveness probe asks whether the process is alive enough to respond. A readiness probe asks whether it should receive user traffic. A process can be live but not ready while its required model, configuration, disk, or downstream service is unavailable.

Liveness should be cheap and local. Do not generate model text in it: slow inference during overload could trigger restarts and make the outage worse. Readiness may check required inventory or a dependency with a short timeout, but should still avoid expensive work.

Analogy: A restaurant's lights being on proves it exists. Being staffed, stocked, and able to take orders proves it is ready.

Scenario: A FastAPI process returns ready without checking its model marker. The load balancer sends traffic to it, and every real request fails after admission.

Return small machine-readable objects with stable status fields. In production, readiness failure normally removes an instance from load balancing; liveness failure may cause an orchestrator to restart it.