Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


Readiness Probe


A liveness probe makes sure that your pod is in good health, but for some applications it isn’t enough. Some applications need to load large files before starting. You might think if you set a higher initialDelaySeconds value then the problem is solved but this is not an efficient solution. The readiness probe is a solution especially for Kubernetes services, as the pod will not receive the traffic until it is ready. Whenever the readiness probe fails, the endpoint for the pod is removed from the service and it will be added back when the readiness probe succeeds. The readiness probe is configured in the same way as the liveness probe:


It’s recommended to use both the readiness probe and the liveness probe whereby the liveness probe restarts the pod if it failed and the readiness probe makes sure the pod is ready before it gets traffic.

Probe Parameters

Probes have a number of parameters that you can use to more precisely control the behavior of liveness and readiness checks.

  • initialDelaySeconds: Number of seconds after the container has started before liveness or readiness probes are initiated.

  • periodSeconds: How often (in seconds) to perform the probe. Default is 10 seconds. Minimum value is 1.

  • timeoutSeconds: Number of seconds after which the probe times out. Defaults to 1 second. Minimum value is 1.

  • successThreshold: Minimum consecutive successes for the probe to be considered successful after having failed. Defaults to 1. Must be 1 for liveness. Minimum value is 1.

  • failureThreshold: When a pod starts and the probe fails, Kubernetes will try failureThreshold times before giving up. Giving up in case of a liveness probe means restarting the pod. In case of a readiness probe the pod will be marked Unready. Defaults to 3. Minimum value is 1.

And HTTP probes have additional parameters that can be set on httpGet:

  • host: The host name to connect to, which defaults to the pod IP. You probably want to set “Host” in httpHeaders instead.

  • scheme: The scheme to use for connecting to the host (HTTP or HTTPS). Defaults to HTTP.

  • path: Path to access on the HTTP server.

  • httpHeaders: Custom headers to set in the request. HTTP allows repeated headers.

  • port: Name or number of the port to access on the container. Number must be in the range 1 to 65535.