Kubernetes Health Checks: Explain Readiness, Liveness and Startup

Begin with the failure you want to detect

Kubernetes health checks are easier to explain when you connect each probe to an operational decision. A process can be running while unable to serve a request, and an application that starts slowly may need time before ordinary checks are useful. Define those states before selecting an endpoint.

In a DevOps interview or portfolio demonstration, describe the application, the failure mode and the intended response. A copied configuration is less informative than an explanation of why the check exists and what should happen when it fails.

Keep the three probe purposes separate

A readiness probe indicates whether the container is ready to accept traffic. A liveness probe is used to determine whether a container should be restarted. A startup probe allows startup to be assessed before configured liveness and readiness checks take over. The official Kubernetes probe documentation explains these distinct behaviours.

Do not use one heavy dependency check for every purpose without considering the consequences. A temporary downstream problem may require a different response from a stuck application process. Think through whether removing an instance from traffic, restarting it or waiting is likely to help.

Build a small, controlled demonstration

Use a disposable development environment and an application with observable startup, readiness and failure states. Keep the checks lightweight. Record what the application reports and what Kubernetes does, rather than assuming that a successful configuration file proves the behaviour.

Run separate experiments for slow startup, temporary unavailability and a process that can no longer make progress. Change one condition at a time. Keep logs and timestamps so another engineer can follow the sequence without having to guess which setting caused the result.

Discuss thresholds as an operational trade-off

There is no single probe interval or failure threshold that is right for every service. Consider startup behaviour, request patterns, resource constraints and what a restart actually repairs. Excessively sensitive checks can create unnecessary disruption, while slow detection can delay recovery.

Explain how you would review the settings with the application team and validate them outside production first. Include alerting, investigation and recovery procedures in the discussion. Probes are one mechanism in an operating approach; they do not replace an understanding of the service.

Use the example to show engineering judgement

A strong explanation covers intent, observed behaviour and limitations. Be ready to say what you would monitor after deployment and how you would adjust the checks as the application changes. Browse cloud and DevOps vacancies and use the responsibilities to guide which operational examples you prepare.