An app takes 90 seconds to load a large model at boot, but you only configured a liveness probe that starts checking after 10 seconds. What likely happens?

It gets restarted repeatedly and never finishes loading, a crash loop

It's kept out of the load balancer until loading finishes, then serves traffic

It gets restarted repeatedly and never finishes loading, a crash loop

🩺 Your container is running — but is it actually working?

A running process isn't the same as a healthy one. A web app can be alive yet frozen on a deadlock, or booted but still loading a 2 GB model into memory. To tell the difference, Kubernetes doesn't trust that a container is up just because its process exists — it repeatedly pokes each container with health probes and acts on the answers.

There are three, and the key is what failure triggers. A failing liveness probe means "this container is wedged" — Kubernetes kills and restarts it. A failing readiness probe means "alive, but not ready for traffic right now" — Kubernetes leaves it running but removes it from the load balancer's endpoints, so no requests are routed to it until it recovers. The third, the startup probe, holds off the other two until a slow-booting app has finished coming up.

This split matters in practice: a temporarily overloaded pod should stop receiving requests, not get killed — that's a readiness job. And a slow starter with only a liveness probe can get stuck in a crash loop, restarted over and over before it ever finishes booting, which is exactly the trap startup probes were added to fix.