DevOps

Kubernetes Probe Configurator

Generate liveness, readiness and startup probe configuration with timings derived from your application start and response times, and avoid the restart loops a wrong probe causes.

Last reviewed by the Radiatus Cloud team

Probe configuration appears here.

Want this automated for your stack?

We build CI/CD, Kubernetes & IaC pipelines that scale.

Talk to an engineer

Three probes that do completely different things

A readiness probe controls whether the pod receives traffic. A liveness probe controls whether the container is killed and restarted. A startup probe suspends the other two until the application has finished booting. Conflating them is the most common Kubernetes configuration error there is, and the usual symptom is a pod that restarts forever because a liveness probe fired during a slow start that a startup probe should have covered.

Liveness probes should almost never check dependencies

If a liveness endpoint queries the database, then a database outage restarts every pod in the deployment simultaneously, turning a recoverable dependency failure into a full outage with an empty cache and a thundering herd on recovery. A liveness probe should answer one question: is this process wedged such that only a restart will help. Dependency health belongs in the readiness probe, where failing simply removes the pod from the load balancer until the dependency returns.

The timings multiply

Failure is declared after failureThreshold consecutive failures spaced by periodSeconds, each waiting up to timeoutSeconds. A liveness probe with a period of 10, a timeout of 1 and a threshold of 3 kills a container roughly 30 seconds after it stops responding, but if the application takes 40 seconds to start and there is no startup probe, it never gets that far. Deriving the numbers from measured start and response times, rather than copying a manifest, is what stops the loop.

Related tools

Frequently Asked Questions

What is a startup probe for?

It suspends the liveness and readiness probes until the application has finished booting, so a slow start does not trigger restarts. It is the correct fix for a container that restarts during startup, and it is far better than inflating initialDelaySeconds on the liveness probe, which then delays real failure detection for the whole life of the pod.

Should a liveness probe check the database?

No. If it does, a database outage restarts every pod at once and turns a recoverable dependency failure into a full outage with cold caches. Dependency checks belong in the readiness probe, where failing only removes the pod from the load balancer.

How long until a failing container is restarted?

Roughly initialDelaySeconds plus failureThreshold times periodSeconds, with each check allowed up to timeoutSeconds. The tool calculates this so the detection window is explicit rather than implied.

Do I need all three probes?

Readiness almost always, since without it traffic arrives before the application can serve it. Startup whenever boot time varies or exceeds about twenty seconds. Liveness only when the application can genuinely deadlock in a way a restart fixes; adding one reflexively creates restart loops more often than it fixes anything.

What happens if readiness fails on every pod?

The service has no endpoints and traffic fails, but nothing is restarted, so the pods recover as soon as the underlying cause does. That is exactly the intended behaviour and the reason dependency checks belong here rather than in liveness.

Privacy & Security

Everything runs in your browser; nothing is uploaded.

Data: None
Client-side-Side
Active
v1.0

How to Use

Enter your application start time and endpoint behaviour to get correctly timed probe YAML.

Disclaimer: This tool is provided "as is" without warranty of any kind. Results are for educational and utility purposes.