>_SecOpsLog_
BlogKubernetes

Kubernetes liveness, readiness, startup probes done right

Stop routing traffic to pods that aren't ready and restarts that make outages worse — the three probes explained.

Jun 24, 2025·8 min readIntermediate

Kubernetes has three health probes and they do different things. Readiness decides if a pod receives traffic. Liveness decides if it gets restarted. Startup buys a slow-booting app time before the other two kick in. Confuse them and you turn a small hiccup into an outage.

Readiness vs liveness
Readiness
gates Service traffic
fail -> removed from endpoints
no restart
use for warm-up + deps
Liveness
detects a wedged process
fail -> container restarted
restarts, cost real
use for deadlock only
deploy.yaml
readinessProbe:
  httpGet: { path: /ready, port: 8080 }
  periodSeconds: 5
livenessProbe:
  httpGet: { path: /healthz, port: 8080 }
  periodSeconds: 10
  failureThreshold: 3
Never check dependencies in liveness
If /healthz pings the database, a DB blip restarts every pod at once — a self-inflicted outage. Liveness should only reflect *this* process being alive. Dependency checks belong in readiness.

Startup probe for slow boots

A JVM that takes 60s to warm up will be liveness-killed before it ever serves. A startup probe holds liveness/readiness off until the app is up.

deploy.yaml
startupProbe:
  httpGet: { path: /healthz, port: 8080 }
  failureThreshold: 30
  periodSeconds: 5     # up to 150s to start, then liveness takes over
Go deeper in a courseKubernetes administrationProbes, rollouts, and running workloads reliably.View course

Related posts

Kubernetes network policies: default-deny, keep DNS upJul 3, 2026 · 11 minPod Security Standards: enforce restricted without breakageApr 28, 2026 · 12 minKubernetes RBAC least privilege: from admin to scoped rolesApr 14, 2026 · 10 min