Work back from your health-check settings to what they produce
Container orchestrators check application state with probes. Enter the period, timeout, failure threshold and success threshold, and this page computes the worst-case time from the moment a fault starts until the instance is declared unhealthy, along with how likely a healthy instance is to be marked failed. A short period detects faults sooner but raises false alarms; a long one does the opposite.
As in Kubernetes, the model starts a probe every period. Worst-case detection is failure threshold x period + timeout, and the result area prints the formula that was applied. The startup allowance uses the failure threshold x period formula that the Kubernetes documentation states for startup probes. A liveness failure restarts the container, a readiness failure removes it from traffic, and a startup probe protects slow initialization, so the three roles differ. Current as of October 2026.
There is no official recommended period, timeout or threshold. Response-time distributions differ per workload, so this page suggests no values and only reports what your own settings produce. The false-alarm interval is a simple calculation that assumes probe failures are independent; in practice load spikes make failures cluster. Looking up platform defaults and generating configuration files are not supported.
Frequently Asked Questions
A single slow response marks the instance unhealthy at once. Detection is fastest, but false alarms on a healthy instance are also most frequent.
Healthy responses are cut off as timeouts. Enter your p99 response time and the page shows the margin against the timeout in milliseconds, so check whether that margin is zero or below.
The roles differ, so the outcome differs. A liveness failure restarts the container while a readiness failure only removes it from traffic, so many setups keep liveness looser because it goes as far as a restart.