Docker & Containers' bug-reference lesson showed one specific probe failure mode — a liveness probe firing too early and causing a false CrashLoopBackOff. This lesson is the fuller picture: three distinct probe types, each answering a genuinely different question about a container's health.
3 min read
Kubernetes doesn't have one generic "is this container okay" check — it
has three probe types, each answering a different question, because
conflating them is exactly what caused the false CrashLoopBackOff from
Docker & Containers' bug reference:
A liveness probe checks whether a running container is still functioning — if it fails repeatedly, Kubernetes kills and restarts the container, assuming it's stuck in a bad state a restart might fix (a deadlock, an unrecoverable internal error):
livenessProbe:
httpGet:
path: /health
port: 3000
initialDelaySeconds: 10
periodSeconds: 10
failureThreshold: 3Liveness probes should check the narrowest possible thing: "is the process itself still able to respond at all," not "are all my dependencies healthy" — a liveness check that fails because a downstream database is temporarily unreachable causes Kubernetes to restart a perfectly healthy application container repeatedly, which won't fix a database outage and actively makes recovery harder by adding restart churn on top of it.
A readiness probe checks whether a Pod is currently able to handle requests — if it fails, the Pod is removed from the Service's routing (from Docker & Containers' Services lesson) without being restarted, and added back automatically once the probe passes again:
readinessProbe:
httpGet:
path: /ready
port: 3000
periodSeconds: 5This is the right place to check dependencies a request actually needs — "can I reach the database right now" is a legitimate readiness check, because the correct response to a temporarily unreachable database is "stop sending this Pod traffic until it recovers," not "restart the container," which is exactly why this belongs in readiness, not liveness.
A startup probe exists specifically to solve Docker & Containers'
false-CrashLoopBackOff bug at the root: for a slow-booting application
(loading a large dataset, warming an in-memory cache), a startup probe
runs first and suppresses liveness checks entirely until it succeeds:
startupProbe:
httpGet:
path: /health
port: 3000
failureThreshold: 30
periodSeconds: 5
# allows up to 30 * 5 = 150 seconds to boot before liveness checks beginThis is the correct fix for that bug — rather than just raising a
liveness probe's initialDelaySeconds (which works, but caps at one fixed
number and can't distinguish "still legitimately booting" from "stuck"
once that window passes), a startup probe explicitly separates "give it
time to boot" from "is it healthy once running," letting liveness checks
stay tight and responsive once startup genuinely completes.
Using one endpoint for all three probe types, or setting overly aggressive
thresholds, produces exactly the two failure modes this domain keeps
returning to: a healthy Pod restarted unnecessarily (wasted availability,
dropped in-flight requests) or an unhealthy Pod kept receiving traffic it
can't actually serve (real user-facing errors). Designing each probe
endpoint to check only what that specific probe type should be asking is
the actual discipline behind reliable production behavior — not a
one-size-fits-all /health endpoint reused for everything.
Check your understanding
A quick comprehension check — not tracked, not graded, just for you.
1. Why should a liveness probe avoid checking whether a downstream dependency (like a database) is healthy?
2. What's the difference between a readiness probe failing and a liveness probe failing?
3. What specific bug does a startup probe solve, compared to just raising a liveness probe's initialDelaySeconds?
Kubernetes