Startup calls run first; readiness and liveness begin only after the startup check succeeds.

Startup probes delay other probes until initialization succeeds

A startup probe gives a container a separate initialization contract. While that configured probe has not succeeded, Kubernetes does not execute the container’s liveness or readiness probes. This is stronger and more specific than ignoring some liveness failures during a grace period: those other checks have not begun. Once startup succeeds, ordinary ongoing health and readiness behavior takes over. ...

August 22, 2027 · 6 min · XB Field Notes
One Pod keeps its identity through readiness changes and a later container restart.

Readiness changes routing eligibility; liveness restarts a container

Readiness and liveness answer different operational questions. Readiness asks whether this container should contribute to a Pod that accepts ordinary Service traffic now. Liveness asks whether restarting this container is the configured recovery action. Both can use HTTP, but sharing a protocol does not make their meanings interchangeable. Define the action you want before choosing the condition that triggers it. ...

January 13, 2027 · 6 min · XB Field Notes