Kubernetes startup, readiness and liveness probes: choose the failure action first

By the Just Create App team

A health endpoint becomes useful when a team agrees what a failed response should do. Should traffic stop? Should a container restart? Or should the application have more time to finish starting?

Kubernetes gives those questions separate names: startup, readiness and liveness. They are not three interchangeable ways to ask whether a port is open.

This documentation-based guide explains the decision before the configuration. It is not a production test, a deployment recipe or a claim of measured availability.

Write the failure action before the endpoint

A probe is a periodic diagnostic performed by the kubelet. The Kubernetes probe documentation describes checks that execute code in a container or make a network request.

The distinction that matters is the response to failure:

• A startup probe allows time for initialization. When one is configured, liveness and readiness probes do not run until it succeeds. Repeated startup-probe failure can lead to the container being killed and handled according to its restart policy.
• A readiness probe determines whether the container is ready to receive traffic. Failed readiness stops service traffic to the unready Pod without using that failure as a restart request.
• A liveness probe is for deciding that a container should restart after the configured failure tolerance is exceeded.

Our load-balancer guide explains the traffic-routing layer. Readiness supplies a different part of the picture: whether a particular instance should be in the traffic pool now. A running process and an eligible backend are not the same fact.

A slow startup is not automatically a dead process

Consider a container that must load configuration before it can serve requests. A short liveness timeout may restart it while it is making legitimate progress. The next container starts the same work again, and the loop continues.

A startup probe can separate initialization from the steady-state liveness check. The official documentation describes choosing a startup failure tolerance large enough for startup rather than stretching the normal liveness policy for every later check.

There is no universal startup allowance. Measure the behavior of your own application and state which condition completes initialization. This article deliberately supplies no numeric setting that readers might mistake for a safe default for every workload.

An unready application may need recovery time, not a restart

Suppose a backend temporarily cannot perform the user operation that its Service routes to it. Readiness can report that it is not eligible to receive that work. The container continues running while probes check for recovery.

The effect differs from liveness. Restarting a healthy process because a shared dependency is unavailable may add startup work without repairing the dependency. Kubernetes specifically warns that incorrect liveness checks can cause cascading failures.

Do not turn every downstream timeout into a restart decision. Ask whether restarting this container can address the condition. Separately ask whether it can still serve the requests it would receive. Those answers belong to the application's design, not the endpoint's name.

Review timing as a policy, not an isolated field

Probe intervals, timeouts and consecutive success or failure thresholds work together. A successful sample is not a promise that the next user request will succeed. A failure also needs interpretation in the context of the configured tolerance.

Kubernetes documents different constraints for different probe types. For example, the success threshold must be one for liveness and startup probes. A failed readiness probe does not stop the container from running or prevent further readiness checks.

Before deployment, read the documentation for the Kubernetes version you run. Test startup, an application failure, a dependency outage and recovery. Record what actually happens to traffic and container restarts instead of assuming that the dashboard label tells the whole story.

A small review sheet

For each probe, write:

• The condition it observes.
• The action repeated failure should cause.
• Why that action helps this workload.
• The timing and thresholds, with a reason for each.
• The failure and recovery scenario that will test the policy.

If two probes use the same endpoint, explain why that endpoint supports both decisions. Sharing an endpoint can be deliberate; treating the decisions as identical is the mistake.

Choose the intended action first. Then choose the endpoint and configuration that provide evidence for it.

Source and limits

Source: Kubernetes, Liveness, Readiness, and Startup Probes, checked 7 October 2026. This is an explanatory companion from the Just Create App team. No production benchmark, original incident, certification or client-project experience is claimed.