When should you use liveness, readiness and startup probes?

Each probe answers a different question. Liveness asks whether the process should be restarted. Readiness asks whether it can serve traffic right now. Startup asks whether initialization has finished, and while it runs, liveness and readiness checks are suppressed.

• Liveness should check the process itself, not downstream dependencies
• Readiness should reflect the ability to serve requests, including warm caches and dependency checks
• Startup probes are for slow boots such as JVM or model loading
• Set initialDelaySeconds, periodSeconds, timeoutSeconds, failureThreshold and successThreshold deliberately
• A liveness probe that depends on a database can restart every pod during a database outage

startupProbe:
  httpGet:
    path: /healthz
    port: 8080
  failureThreshold: 30
  periodSeconds: 2
readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  periodSeconds: 5
  failureThreshold: 3
livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  periodSeconds: 10
  failureThreshold: 3

Probes are part of rollout safety. If readiness is wrong, a broken release receives traffic. If liveness is too aggressive, healthy pods restart during load. Test probes under real startup and dependency failure conditions rather than assuming the endpoints behave correctly.