Describe how your container reports health and how long it takes to start. Get probe YAML for the deployment and the timing math: how long startup may take, and how fast a failure is noticed.
Runs entirely in your browser — nothing you enter here is sent to a server.
Kubernetes cannot tell whether your application works; it can only see that a process is running. Probes are how you tell it more. Each probe asks a different question and triggers a different action, and most probe-related outages come from mixing them up.
"Has the application finished starting?" Until it passes, the other probes are held back. It gives slow starters time without slowing failure detection afterwards.
"Is the process stuck beyond recovery?" On failure the container is restarted. Check only the process itself — never its dependencies.
"Can this pod take traffic right now?" On failure the pod is removed from the Service but left running. It may check dependencies the pod cannot work without.
periodSeconds × failureThreshold is how long a problem lasts before Kubernetes acts. Shorter is faster, and more likely to act on a blip.
A liveness probe that checks the database. When the database slows down, every pod fails liveness and is restarted together. The restarted pods reconnect all at once and make the database slower still. Liveness should answer "is this process alive?" and nothing else.
A timeout tighter than the application under load. The default timeoutSeconds is 1. A health endpoint that takes 1.2 seconds during a traffic peak fails, pods are restarted, the remaining pods carry more load and fail too. Make the health endpoint cheap and give it room.
No startup probe on a slow starter. A liveness probe that begins before the app is ready kills it in a loop — CrashLoopBackOff — especially after a change that makes startup a little slower than before.
A failed liveness probe restarts the container; a failed readiness probe only stops traffic being sent to the pod. Use readiness for temporary conditions and liveness for states that only a restart can fix.
Whenever startup can take longer than the liveness probe would tolerate — typically more than 20 to 30 seconds. The startup probe gives the application time once, then hands over to the liveness probe.
Roughly periodSeconds × failureThreshold plus the timeout. With the common 10-second period and threshold of 3, about 30 seconds after the container stops responding.
No. If a shared dependency fails, all pods fail liveness at once and are restarted, which does not fix the dependency and removes your whole capacity. Put dependency checks in readiness, if anywhere.
Upzilla checks your service from the outside — through DNS, the load balancer and TLS — the way a user reaches it. 10 monitors free.