Kubernetes Health Checks Explained: Readiness, Liveness, and Startup Probe Checklist

Overview

Kubernetes probes are health checks run by the kubelet against containers in a Pod. Although all three probe types can use HTTP, TCP, or an executable command, they answer different operational questions:

• Readiness probe: Is this container ready to receive application traffic?
• Liveness probe: Is this container still functioning, or should Kubernetes restart it?
• Startup probe: Has this slow-starting container finished initializing so the other probes can take over?

The distinction matters. A failed readiness probe normally removes a Pod from the endpoints used by a Service, while a failed liveness probe can cause the container to restart. A startup probe temporarily controls the startup phase and prevents liveness or readiness checks from acting too aggressively before initialization is complete.

These checks do not replace application monitoring. A probe should be a small, predictable signal that represents a specific operational decision. It should not perform an expensive dependency audit, expose sensitive diagnostics, or require every downstream system to be available unless that dependency is genuinely necessary for the decision being made.

For broader diagnosis, pair this approach with a documented Kubernetes troubleshooting runbook. Probes identify a symptom and influence workload behavior; logs, metrics, traces, and events help explain the cause.

What to track

Readiness: control traffic, not process survival

Use a readiness probe when a running process may still be unable to serve requests. Common examples include an application that is loading configuration, warming a cache, waiting for a required local resource, or temporarily unable to handle requests after losing a needed connection.

A readiness failure should generally be recoverable without restarting the container. Keep the endpoint focused on whether the instance can safely serve the type of traffic routed to it. If the application is alive but overloaded or in a controlled drain, returning a readiness failure can allow traffic to move elsewhere while preserving the process for inspection.

Liveness: detect a condition that requires restart

Use a liveness probe for failures from which the process is unlikely to recover without a restart, such as a deadlock or an event loop that has stopped making progress. A liveness endpoint should be less dependent on external services than a readiness endpoint. If it fails whenever a database or remote API is unavailable, Kubernetes may restart every replica even though restarting cannot fix the dependency outage.

That behavior can increase load during an incident and erase useful debugging state. Before adding a liveness check, define the failure it is intended to recover from and confirm that a restart is an appropriate response.

Startup: protect slow initialization

Use a startup probe when an application has a variable or lengthy initialization period. While the startup probe has not succeeded, Kubernetes does not run the liveness and readiness probes. Once startup succeeds, the normal probes become active.

This is usually safer than setting a very large initial delay on a liveness probe. A startup probe can express a bounded startup budget using its interval, timeout, and failure threshold. If that budget is exceeded, the container is treated as failed and may be restarted.

Choose the probe mechanism carefully

• HTTP: Useful when the application can expose a small health endpoint. Confirm that the expected status code and path are correct.
• TCP: Confirms that a port accepts connections, but does not prove that the application can process a request correctly.
• Exec: Useful for a local check that cannot be represented by HTTP or TCP, but keep the command fast and account for process and shell behavior.

Track the endpoint contract, the intended failure response, probe duration, failure counts, restart counts, and the relationship between probe failures and user-visible errors. Also record which configuration change, deployment, or infrastructure event preceded a change in those values.

Cadence and checkpoints

Review probes at three levels: during development, after every relevant release, and on a recurring operational cadence. A monthly or quarterly review is useful for stable systems, while high-change workloads may need a shorter interval.

During implementation

Write down the operational meaning of each endpoint before adding it to the manifest. Ask:

• What exact condition makes the container ready for traffic?
• What failure indicates that a restart could help?
• How long can normal startup take under the slowest expected conditions?
• What happens when a dependency is unavailable?
• Can the endpoint respond within the configured timeout under normal load?

After a deployment or configuration change

Check probe events, rollout progress, readiness duration, container restarts, and Service endpoints. Compare the result with the previous release rather than looking only at whether the rollout eventually completed. A rollout that succeeds after repeated readiness failures may still indicate a fragile startup path.

Example manifest

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  template:
    spec:
      containers:
        - name: api
          image: example/api:stable
          ports:
            - name: http
              containerPort: 8080
          startupProbe:
            httpGet:
              path: /health/startup
              port: http
            periodSeconds: 5
            timeoutSeconds: 2
            failureThreshold: 24
          readinessProbe:
            httpGet:
              path: /health/ready
              port: http
            periodSeconds: 5
            timeoutSeconds: 2
            failureThreshold: 3
            successThreshold: 1
          livenessProbe:
            httpGet:
              path: /health/live
              port: http
            periodSeconds: 10
            timeoutSeconds: 2
            failureThreshold: 3

The values above are examples, not universal defaults. Tune them from observed startup and response behavior. A short timeout is appropriate only if the application consistently responds within that window under realistic resource pressure.

How to interpret changes

Probe failures are signals, not diagnoses. Interpret them alongside events, logs, resource metrics, deployment history, and traffic patterns.

• Readiness failures with no restarts: Investigate dependency availability, configuration, overload, connection pools, or an endpoint that is stricter than the traffic path requires.
• Liveness failures followed by restarts: Check for deadlocks, memory pressure, blocked startup logic, probe timeouts, and whether the liveness endpoint performs external calls.
• Startup failures: Compare the configured startup budget with image pull completion, migration duration, configuration loading, and the slowest normal initialization path.
• Probe timeouts during load: Check CPU throttling, memory pressure, network latency, request queueing, and whether the health handler shares scarce resources with expensive application work.
• Healthy probes but failed requests: The check may be too shallow. A process can accept a health request while a particular API route, dependency, or queue is failing.

Use kubectl describe pod to inspect events and probe failures, then review logs with kubectl logs. Check current container state and restart counts with kubectl get pod -o wide or a custom column view. To confirm whether a Service has usable backends, inspect its EndpointSlices with kubectl get endpointslice. These commands help separate a probe configuration problem from a wider scheduling, networking, or application problem.

When a probe fails, avoid immediately increasing every threshold. First determine whether the failure is caused by a real application condition, an incorrect path or port, an overly expensive check, or a timeout that does not match observed behavior. If the change is part of an incident, capture the decision and outcome in the team’s incident response runbook.

When to revisit

Revisit Kubernetes health checks after application changes, dependency changes, container image changes, resource-limit changes, network-policy updates, and changes to startup tasks such as migrations or cache warming. Also review them after an incident involving traffic removal, unexpected restarts, slow rollouts, or cascading dependency failures.

On a monthly or quarterly schedule, use this checklist for each production workload:

1. Confirm that readiness, liveness, and startup probes still have distinct purposes.
2. Verify that paths, ports, protocols, and authentication behavior match the deployed application.
3. Compare startup duration and probe latency with configured thresholds.
4. Review readiness failures, liveness-triggered restarts, and startup failures for recurring patterns.
5. Test dependency outages and graceful recovery in a suitable non-production environment.
6. Check that health endpoints reveal no credentials, tokens, internal error details, or unnecessary system data.
7. Record the owner, expected behavior, and last review date alongside the workload documentation.

Finally, treat probe configuration as part of the release contract, not as a one-time deployment detail. Add probe review to pull requests that change startup logic, service dependencies, ports, or resource settings. When the application’s behavior changes, update the endpoint semantics, thresholds, dashboards, and runbooks together. That recurring discipline keeps health checks useful for traffic management and recovery without turning them into a source of avoidable restarts.