Kubernetes liveness, readiness and startup probes explained

By LearnSome.tech · Published 2026-11-04

TL;DR

A liveness probe tells Kubernetes when to restart a container, and a readiness probe decides when it is ready to accept traffic. Until a startup probe succeeds, Kubernetes runs neither of the other two, which gives a slow app time to finish starting. Failing liveness or startup gets the container killed, while failing readiness only stops traffic from matching Services.

What does each Kubernetes probe do?

A probe is a diagnostic the kubelet performs periodically on a container, either by executing code within it or by making a network request.

  • Liveness decides when to restart a container, for example to recover from a deadlock where the app is running but unable to make progress.
  • Readiness decides when a container is ready to accept traffic; when it fails, the Pod's IP address is removed from the EndpointSlices of every matching Service.
  • Startup checks whether the application in the container has started, and it runs only at startup, unlike the other two, which run periodically.

Adding a readiness probe means the Pod will start without receiving any traffic and only start receiving traffic after the probe starts succeeding. That matters for apps with time-consuming initial tasks, such as establishing network connections, loading files and warming caches.

What happens when a probe fails?

When a liveness or startup probe fails, the kubelet kills the container, and the container is then subject to its restart policy. A failed readiness probe is gentler: the kubelet keeps the container running, keeps probing, and sets the Pod's Ready condition to false.

The kubelet restarts exited containers with an exponential backoff delay: 10s, 20s, 40s and so on, capped at 300 seconds. When a Pod keeps failing to start, kubectl can show CrashLoopBackOff in its Status field. Liveness or startup probes returning a Failure result are one of the issues that can cause CrashLoopBackOff. So before you ship a new liveness probe, try it against a slow or overloaded copy of the app.

How do you write all three probes for one container?

Below is a setup for a web API that listens on port 8080.

containers:
- name: api
  image: registry.example.com/orders-api:1.4.2
  ports:
  - name: http            # probes use this name, so they follow the port
    containerPort: 8080
  startupProbe:           # up to 12 x 10s = two minutes to boot
    httpGet:
      path: /healthz      # same check as liveness
      port: http
    periodSeconds: 10
    failureThreshold: 12
  livenessProbe:          # runs only after startup succeeds
    httpGet:
      path: /healthz
      port: http
    periodSeconds: 10
    timeoutSeconds: 2
    failureThreshold: 3   # restart after 3 failures in a row
  readinessProbe:         # its own endpoint: may also check dependencies
    httpGet:
      path: /ready
      port: http
    periodSeconds: 5
    failureThreshold: 2   # out of the Service after 2 failures

The startup probe runs the same HTTP check as liveness, with failureThreshold × periodSeconds long enough to cover the worst case startup time. Once the startup probe has succeeded, the liveness probe takes over to give a fast response to container deadlocks. Kubernetes considers a check failed after the probe fails failureThreshold times in a row.

In the example, that endpoint is /ready. The liveness probe passes when the app itself is healthy, but the readiness probe can also check that each required back-end service is available. An HTTP check is successful if the response has a status code greater than or equal to 200 and less than 400. You can use a named port for HTTP and TCP probes.

What are the default timings, and which should you change?

Check each of these defaults against how your app really behaves.

  • initialDelaySeconds is the number of seconds after the container has started before any probe begins, and it defaults to 0 seconds.
  • periodSeconds is how often to perform the probe, and it defaults to 10 seconds.
  • timeoutSeconds is the number of seconds after which the probe times out, and it defaults to 1 second.
  • failureThreshold is how many failures in a row count as a failed check, and it defaults to 3.
  • successThreshold is the minimum consecutive successes after a failure, defaults to 1, and must be 1 for liveness and startup probes.

Of these, give the timeout the most thought. If your health endpoint queries a database, time it under load before you trust a one-second limit. Keep health checks cheap, or raise the timeout for that one probe. Kubernetes strongly recommends dedicated health check endpoints that return a minimal response body, and the kubelet stops reading the body after 10KiB.

Which probe mistakes cause restart loops and lost traffic?

These are the probe mistakes worth checking for first. To verify that a liveness probe has failed and the container has been restarted, view the Pod events with kubectl describe pod.

  • Incorrect implementation of liveness probes can lead to cascading failures.
  • A slow starter with only a liveness probe: rather than set a long liveness interval, give the container a separate startup probe that allows a time longer than the liveness interval would allow.
  • Expecting liveness to wait for readiness: liveness probes do not wait for readiness probes to succeed, so delay them with initialDelaySeconds or a startup probe.
  • Before you apply a probe, call the same port and path from inside the Pod and check the status code you get back.

So let liveness pass when the app itself is healthy, and let readiness additionally check that each required back-end service is available.

From our labs

In our CKAD course, you learn to tell a Pod that is Running from one that is Ready. You trace the refused request through the probe, the endpoints and the Service, and learn to tell Running from Ready on the way. The repair is one patch to a readiness probe, and the lab grades it on the cluster's state rather than on the command you typed.

In the probes lesson, a Deployment is stuck in a restart loop driven by one of its probes. You diagnose the loop from describe and the events, working out what the failing probe is doing to the container. Then you write all three probes with timing that matches how the application starts and serves. The module's timed drill then asks you to add probes to a live Deployment inside an exam time budget.

Start the free lesson: Running, And Still Down (Certified Kubernetes Application Developer (CKAD) Exam Prep)

The course: Certified Kubernetes Application Developer (CKAD) Exam Prep

Terms in this guide

Sources

Written by the LearnSome.tech team with AI assistance; every fact checked against the cited source.