Skip to main content

How to configure liveness, readiness, and startup probes in Kubernetes

Liveness, readiness, and startup probes let Kubernetes restart stuck containers, withhold traffic from unready pods, and give slow apps time to boot. Tune timing carefully to avoid restart loops.

Difficulty
Intermediate
Duration
30 minutes
Steps
6

Health probes in Kubernetes

Kubernetes uses probes to learn the state of each container. A readiness probe controls whether a pod receives traffic; a liveness probe decides whether the container should be restarted; a startup probe gives slow-booting apps time before the other probes apply. Correct probes are essential for safe rollouts and self-healing.

Prerequisites

  • A Deployment you can edit.
  • An application exposing a lightweight health endpoint, for example /healthz.

Steps

1. Add a health endpoint

Expose an endpoint that returns 200 only when the app can serve requests. Keep it cheap, no heavy database calls on the liveness path.

2. Configure a readiness probe

Kubernetes stops sending traffic when readiness fails, without restarting the pod:

readinessProbe:
  httpGet:
    path: /healthz
    port: 3000
  initialDelaySeconds: 5
  periodSeconds: 10

3. Configure a liveness probe

A failing liveness probe restarts the container. Use it for deadlocks the app cannot recover from:

livenessProbe:
  httpGet:
    path: /healthz
    port: 3000
  periodSeconds: 10
  failureThreshold: 3

4. Add a startup probe for slow apps

For apps with long boot times, a startup probe prevents premature liveness restarts:

startupProbe:
  httpGet:
    path: /healthz
    port: 3000
  failureThreshold: 30
  periodSeconds: 10

The liveness probe begins only after the startup probe passes.

5. Tune timing and thresholds

Avoid aggressive liveness settings that cause restart loops under load. Set initialDelaySeconds and failureThreshold generously, and keep the readiness probe stricter than liveness.

6. Test probe behavior

kubectl describe pod <pod>
kubectl get events --field-selector reason=Unhealthy

Simulate failure by making the endpoint return 500 and watch traffic stop or the pod restart.

Verification

Apply the manifest and run kubectl get pods to confirm pods become Running and READY 1/1. Break the health endpoint and observe readiness removing the pod from the Service endpoints; restore it and confirm traffic returns.

Next Steps

Pair probes with a HorizontalPodAutoscaler and a PodDisruptionBudget for resilient rollouts. Add a separate, deeper readiness check that verifies downstream dependencies without affecting liveness.

Prerequisites

  • A Deployment running in Kubernetes
  • An app with a health endpoint

Steps

  • 1
    Add a health endpoint
  • 2
    Configure a readiness probe
  • 3
    Configure a liveness probe
  • 4
    Add a startup probe for slow apps
  • 5
    Tune timing and thresholds
  • 6
    Test probe behavior

Category

Containers