What is the difference between a liveness probe and a readiness probe, and how do people get them wrong?

A readiness probe controls whether a pod receives traffic; a liveness probe controls whether the kubelet restarts the container. The classic mistake is pointing liveness at a downstream dependency, so a slow database restarts every pod in a loop and turns a partial outage into a total one. Liveness should check only that the process is alive and not deadlocked. Use a startup probe for slow booting applications.

Readiness decides whether the pod is in the service endpoints, liveness decides whether the kubelet kills and restarts the container. The failure I have actually seen is a team that made the liveness endpoint check the database. The database got slow, every pod failed liveness at roughly the same time, the whole deployment went into a restart loop, and now instead of degraded reads we had nothing at all, plus a thundering herd of cold connections when it came back. Liveness should be almost boring: can the process serve a trivial handler, is the event loop not wedged. Anything about dependencies belongs in readiness, because taking a pod out of rotation is reversible and cheap. The other thing I always check is timing. If the app takes 45 seconds to warm caches, either use a startup probe or set initialDelaySeconds and failureThreshold to match, otherwise you have built a machine that can never finish booting.