Liveness, Readiness, and Startup Probes [page]deterministic

concepts

Kubernetes lets you define _probes_ to continuously monitor the health of containers in a Pod. A probe is a diagnostic performed periodically by the [kubelet](#gloss:kubelet) on a container. To perform a diagnostic, the kubelet either executes code within the container or makes a network request.

Based on the probe results, Kubernetes can restart unhealthy containers or stop sending traffic to containers that are not ready.

## Types of probe {#types-of-probe}

The kubelet can optionally perform and react to three kinds of probes on running containers, each serving a different purpose:

[Startup probe](#startup-probe)
[Liveness probe](#liveness-probe)
[Readiness probe](#readiness-probe)

### Startup probe {#startup-probe}

Startup probes verify whether the application within a container is started. If a startup probe is configured, Kubernetes does not execute liveness or readiness probes until the startup probe succeeds, allowing the application time to finish its initialization.

This type of probe is only executed at startup, unlike liveness and readiness probes, which are run periodically. If the startup probe fails, the kubelet kills the container, and the container is subjected to its [restart policy](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy).

### Liveness probe {#liveness-probe}

Liveness probes determine when to restart a container. For example, liveness probes could catch a deadlock, where an application is running, but unable to make progress. Restarting a container in such a state can help to make the application more available despite bugs.

If a container fails its liveness probe more times than the configured tolerance, the kubelet restarts that container. Liveness probes do not wait for readiness probes to succeed. If you want to wait before executing a liveness probe, you can either define `initialDelaySeconds` or use a [startup probe](#startup-probe).

> Caution: Liveness probes can be a powerful way to recover from application failures, but they should be used with caution. Liveness probes must be configured carefully to ensure that they truly indicate unrecoverable application failure, for example a deadlock.

Incorrect implementation of liveness probes can lead to cascading failures. This results in restarting of container under high load; failed client requests as your application became less scalable; and increased workload on remaining pods due to some failed pods. Understand the difference between liveness and readiness probes and when to apply them for your app.

### Readiness probe {#readiness-probe}

Readiness probes determine when a container is ready to accept traffic. This is useful when waiting for an application to perform time-consuming initial tasks, such as establishing network connections, loading files, and warming caches. Readiness probes can also be useful later in the container’s lifecycle, for example, when recovering from temporary faults or overloads.

If the readiness probe returns a failed state, the [EndpointSlice](#gloss:endpoint-slice) controller removes the Pod's IP address from the EndpointSlices of all Services that match the Pod.

Readiness probes run on the container during its whole lifecycle.

> Note: If you want to be able to drain requests when the Pod is deleted, you do not necessarily need a readiness probe; when the Pod is deleted, the corresponding endpoint in the EndpointSlice will update its [conditions](https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/#conditions): the endpoint ready condition will be set to false, so load balancers will not use the Pod for regular traffic. See [Pod termination](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) for more information about how the kubelet handles Pod deletion.

## When to use each probe {#when-to-use-each-probe}

### When should you use a startup probe? {#when-should-you-use-a-startup-probe}

Startup probes are useful for Pods that have co …(trimmed)