Kubernetes Liveness Probe Behavior

Kubernetes Liveness Probe Behavior is the specific set of rules that determine how the kubelet uses a livenessProbe to detect a container that is running but functionally unresponsive, and the corrective action it takes once that condition is confirmed. Its defining characteristic, distinguishing it from readiness and startup probes, is that a sustained failure results in the container being forcibly killed and restarted, making liveness probing a self-healing mechanism rather than a traffic-routing signal.

Purpose: Detecting Unrecoverable Deadlock

What Liveness Should Check

A well-designed liveness probe checks only whether the application's internal state is fundamentally broken, deadlocked, permanently wedged, unable to make progress, not whether it is temporarily busy or waiting on a slow dependency. Checking dependency health (a database connection, a downstream API) inside a liveness probe is a common anti-pattern, since it causes the kubelet to restart a container for a problem restarting cannot fix.

containers:
  - name: app
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      periodSeconds: 10
      failureThreshold: 3

Execution Timing

Independent Schedule

Once any startupProbe has succeeded (or if none is defined, once initialDelaySeconds elapses after container start), the liveness probe runs on its own periodSeconds interval for the entire remaining life of the container, continuing even while the container is otherwise healthy and serving traffic normally.

Timeout Handling

If a probe attempt does not complete within timeoutSeconds, it is counted as a failed attempt, identical in effect to the check itself returning a failure response.

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  timeoutSeconds: 1
  periodSeconds: 10
  failureThreshold: 3

Failure Accumulation and Action

Consecutive Failures Required

A single failed liveness check does not trigger a restart. The kubelet must observe failureThreshold consecutive failed attempts before acting, which filters out momentary hiccups such as a garbage collection pause or a brief CPU throttling event.

The Kill-and-Restart Sequence

Once the threshold is crossed, the kubelet terminates the container, following the same graceful termination path as any other stop, preStop hook, SIGTERM, grace period, SIGKILL, and then restarts it according to restartPolicy, incrementing restartCount and recording the prior state in lastState.

lastState:
  terminated:
    reason: Error
    exitCode: 137
restartCount: 4

Interaction With Startup Probes

Deferred Start

If a startupProbe is present, liveness checks do not begin at all until the startup probe succeeds. This prevents an application still performing legitimate slow initialization, cache warming, large dataset loading, from being killed by a liveness probe configured for steady-state response times.

startupProbe:
  httpGet:
    path: /startupz
    port: 8080
  failureThreshold: 30
  periodSeconds: 2
livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  periodSeconds: 10

Consequences of Misconfiguration

Too Aggressive

A liveness probe with a low failureThreshold or short periodSeconds, especially without a startup probe, can cause restart loops on an application that is actually healthy but momentarily slow, producing CrashLoopBackOff on an otherwise functioning service.

Too Permissive

A liveness probe checking only that the process is listening on a port, without verifying actual request-handling capability, may never detect a genuinely deadlocked application, leaving a broken container running indefinitely.

Liveness Probe Flow Diagram

Because the outcome of a liveness failure is always a restart, tuning its thresholds and check semantics carefully is what determines whether liveness probing improves reliability or actively degrades it through unnecessary churn.