What are liveness, readiness, and startup probes, and when do you use each?

Question

IT Interview Practice · Accepted Answer

Probes let the kubelet check a container's health and act on the result. There are three: **liveness** (is it alive, or should it be restarted?), **readiness** (is it ready to receive traffic?), and **startup** (has it finished booting yet?). Each answers a different question.

## The three probes at a glance

```text
LIVENESS   → "Is the app stuck/deadlocked?"   FAIL → kubelet RESTARTS the container
READINESS  → "Can it serve traffic right now?" FAIL → Pod removed from Service endpoints
                                                       (NOT restarted)
STARTUP    → "Has the slow boot finished?"     runs FIRST; while it runs, liveness &
                                                readiness are held off
```

## Readiness vs liveness — the key distinction

```text
Readiness controls TRAFFIC:
  → a Pod that fails readiness is pulled OUT of the Service load-balancer,
    but keeps running (e.g. it's warming a cache or a dependency is down)
Liveness controls LIFE:
  → a Pod that fails liveness is KILLED and restarted (it's broken beyond recovery)
Using liveness where you meant readiness causes needless restart loops.
```

## Probe definitions

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      ports: [{ containerPort: 8080 }]

startupProbe:            # gives a slow starter time before others kick in
        httpGet: { path: /healthz, port: 8080 }
        failureThreshold: 30   # 30 * 10s = up to 5 min to start
        periodSeconds: 10

readinessProbe:          # gate traffic
        httpGet: { path: /ready, port: 8080 }
        initialDelaySeconds: 5
        periodSeconds: 10

livenessProbe:           # restart if unhealthy
        httpGet: { path: /healthz, port: 8080 }
        periodSeconds: 10
        failureThreshold: 3
```

## Probe mechanisms

```text
httpGet    → GET a path; 2xx/3xx = pass         (most common for web apps)
tcpSocket  → can we open a TCP connection?       (for non-HTTP services)
exec       → run a command; exit 0 = pass        (custom checks)
grpc       → native gRPC health check
Key knobs: initialDelaySeconds, periodSeconds, timeoutSeconds,
           failureThreshold, successThreshold.
```

## Why startup probes exist

```text
Slow-starting apps (JVM warmup, big migrations) used to force you to set a huge
initialDelaySeconds on liveness — which then made real crashes slow to detect.
The startupProbe fixes this: it protects the slow boot, and ONLY after it passes
do liveness/readiness begin with their normal (tight) timings.
```

```bash
kubectl describe pod app     # see probe failures & restart reasons in events
kubectl get pod app          # READY column reflects readiness; RESTARTS reflects liveness
```

## Why it matters

Health probes are how Kubernetes delivers self-healing and safe traffic routing, so understanding the three types and when to use each is essential reliability knowledge. The crucial distinction — one that trips up many engineers — is between **readiness** and **liveness**: readiness controls **traffic** (a failing Pod is pulled out of the Service load-balancer but keeps running, ideal when it's warming up or a dependency is temporarily down), while liveness controls **life** (a failing Pod is killed and restarted, for when it's deadlocked beyond recovery). Confusing the two — using a liveness probe where readiness was meant — causes needless restart loops and outages, so knowing which question each probe answers is directly practical. The **startup** probe solves a real historical pain: slow-booting apps once forced huge `initialDelaySeconds` on liveness (which delayed detection of genuine crashes), whereas a startup probe protects the boot window and lets liveness/readiness run with tight, normal timings only once startup succeeds. Understanding the probe mechanisms (`httpGet`, `tcpSocket`, `exec`, `grpc`) and the tuning knobs (`initialDelaySeconds`, `periodSeconds`, `failureThreshold`, etc.) lets you configure health checking correctly rather than by guesswork. Since probes directly determine whether users hit healthy Pods and whether broken Pods recover automatically, getting them right is fundamental to running reliable, production-grade workloads on Kubernetes.

The three probes at a glance

Readiness vs liveness — the key distinction

Probe definitions

Probe mechanisms

Why startup probes exist

Why it matters

Related questions