A container that is running is not necessarily an application that is ready to serve traffic. A web server may still be loading configuration, waiting for a database connection or warming a cache. Kubernetes health probes help the platform make better decisions about when a workload should receive requests and when it needs intervention. Configuring them carelessly, however, can turn a temporary slowdown into a restart loop or an avoidable outage.
Three probes, three separate questions
A readiness probe asks whether a container should receive traffic through the service endpoint right now. A liveness probe asks whether the container is stuck badly enough that restarting it may help. A startup probe gives a slow-starting application extra time before liveness and readiness checks take over. They sound similar, but each is designed for a different operational decision.
Consider an API that starts in forty seconds because it loads a large model. A liveness probe checking too early might restart it after twenty seconds, preventing it from ever becoming healthy. A startup probe can protect that initialization period. Once startup succeeds, readiness determines when traffic can reach the pod, and liveness can detect a genuinely unrecoverable state.
Readiness is about serving requests
Readiness should reflect whether an instance can handle the work it has been assigned. A simple HTTP endpoint might check that the application is initialized and essential components are available. When readiness fails, Kubernetes removes that pod from matching Service endpoints, reducing the chance of routing new traffic to an unhealthy instance.
Do not make readiness depend on every optional downstream service. If a nonessential analytics provider is unavailable, marking every application pod unready could take down the core website too. Decide which dependencies are truly necessary for the endpoint’s purpose. During deployments, readiness is especially useful because it prevents traffic from reaching a new pod before startup work finishes.
Liveness should be conservative
Liveness is not a general-purpose dependency monitor. If every instance checks the same external database and restarts whenever the database is slow, a brief database issue can trigger a storm of restarts across the application fleet. That adds load exactly when the system is already under pressure.
A better liveness signal usually focuses on whether the local process is capable of making progress. Can the event loop respond? Has a worker deadlocked? Is the application irrecoverably stuck? If the issue is external and might recover without restarting the process, readiness or application-level degraded behavior is often more appropriate.
Startup probes for slow initialization
Startup probes are particularly helpful for applications that perform migrations, warm in-memory state or initialize expensive runtimes. While a startup probe is failing, Kubernetes does not execute the other two probe types for that container. Choose a threshold that reflects realistic worst-case startup behavior, not merely the average time on a developer laptop.
For instance, an application that normally starts in twenty seconds but occasionally takes a minute under cold conditions should not have a fifteen-second startup allowance. Otherwise deployments may become unstable during routine node replacements or autoscaling events. Test with production-like data and machine resources.
A small example
The following configuration illustrates the relationship between the three probes. Endpoint names are examples; your application must implement the handlers and return successful HTTP status codes when appropriate.
startupProbe:
httpGet:
path: /health/startup
port: 8080
periodSeconds: 5
failureThreshold: 24
readinessProbe:
httpGet:
path: /health/ready
port: 8080
periodSeconds: 5
failureThreshold: 3
livenessProbe:
httpGet:
path: /health/live
port: 8080
periodSeconds: 10
failureThreshold: 3The startup probe allows up to roughly two minutes of unsuccessful checks before the container is treated as failed. The readiness probe responds to shorter availability changes, while liveness restarts a process only after repeated failed checks. Real detection and termination timing depend on scheduling, timeout settings and application behavior.
Timeouts and resource pressure
A one-second timeout may seem reasonable for a tiny endpoint, but busy nodes, CPU throttling and garbage collection can introduce delays. If probes are too aggressive, healthy applications may be declared unhealthy during bursts. If they are too forgiving, genuine failures persist longer. Measure actual probe latency and failure patterns before settling on thresholds.
Keep health handlers inexpensive. A probe that runs a complex database query every few seconds across hundreds of pods can create its own operational problem. Use cached or lightweight status where possible, and avoid exposing detailed internal information through publicly accessible health endpoints.
Observe failures in context
When a deployment goes wrong, inspect pod events, container logs, restart counts and readiness transitions. Compare them with node pressure, network errors and rollout timing. A failed probe is a symptom, not necessarily the root cause. A sudden wave of readiness failures across multiple services may point to a shared dependency rather than simultaneous application bugs.
Also combine probes with rollout settings, disruption budgets and sensible resource requests. Health checks cannot compensate for deploying too many replicas at once or exhausting node capacity. They are one component of a broader reliability design.
Use the right question for each signal
The easiest mental model is to separate traffic decisions from restart decisions. Readiness says “not ready for requests,” liveness says “restart may help,” and startup says “initialization is still underway.” When teams express those meanings clearly in their endpoints and alerts, Kubernetes becomes more predictable. The goal is not to make every probe green all the time, but to make each failure tell the platform something accurate and actionable.
Further reading: Kubernetes official documentation on probes.
