// Module included in the following assemblies:
// * scalability_and_performance/optimization/routing-optimization.adoc

:_mod-docs-content-type: REFERENCE
[id="ingress-liveness-readiness-startup-probes_{context}"]
= Configuring Ingress Controller liveness, readiness, and startup probes

[role="_abstract"]
As a cluster administrator, you can configure the timeout values for the kubelet liveness, readiness, and startup probes for router deployments that are managed by the {product-title} Ingress Controller (router). The ability to set larger timeout values can reduce the risk of unnecessary and unwanted restarts.

The liveness and readiness probes of the router use the default timeout value of 1 second, which is too brief when networking or runtime performance is severely degraded. Probe timeouts can cause unwanted router restarts that interrupt application connections.

You can update the `timeoutSeconds` value on the `livenessProbe`, `readinessProbe`, and `startupProbe` parameters of the router container.

[cols="3a,8a",options="header"]
|===
 |Parameter |Description

 |`livenessProbe`
 |The `livenessProbe` reports to the kubelet whether a pod is dead and needs to be restarted.

 |`readinessProbe`
 |The `readinessProbe` reports whether a pod is healthy or unhealthy. When the readiness probe reports an unhealthy pod, then the kubelet marks the pod as not ready to accept traffic. Subsequently, the endpoints for that pod are marked as not ready, and this status propagates to the kube-proxy. On cloud platforms with a configured load balancer, the kube-proxy communicates to the cloud load-balancer not to send traffic to the node with that pod.

 |`startupProbe`
 |The `startupProbe` gives the router pod up to 2 minutes to initialize before the kubelet begins sending the router liveness and readiness probes.  This initialization time can prevent routers with many routes or endpoints from prematurely restarting.
|===


[IMPORTANT]
====
The timeout configuration option is an advanced tuning technique that can be used to work around issues. However, these issues should eventually be diagnosed and possibly a support case or https://issues.redhat.com/secure/CreateIssueDetails!init.jspa?pid=12332330&summary=Summary&issuetype=1&priority=10200&versions=12385624[Jira issue] opened for any issues that cause probes to time out.
====

The following example demonstrates how you can directly patch the default router deployment to set a 5-second timeout for the liveness and readiness probes:

[source,terminal]
----
$ oc -n openshift-ingress patch deploy/router-default --type=strategic --patch='{"spec":{"template":{"spec":{"containers":[{"name":"router","livenessProbe":{"timeoutSeconds":5},"readinessProbe":{"timeoutSeconds":5}}]}}}}'
----

.Verification
[source,terminal]
----
$ oc -n openshift-ingress describe deploy/router-default | grep -e Liveness: -e Readiness:
    Liveness:   http-get http://:1936/healthz delay=0s timeout=5s period=10s #success=1 #failure=3
    Readiness:  http-get http://:1936/healthz/ready delay=0s timeout=5s period=10s #success=1 #failure=3
----
