Kubernetes Health Checks: Liveness, Readiness, and Startup Probes
Kubernetes health checks ask your app: "Are you alive?" (liveness), "Ready for traffic?" (readiness), and "Done starting?" (startup). This lets it automate restarts and traffic routing for zero-downtime deployments.
Why it exists
Without health checks, an orchestrator like Kubernetes only knows if a process is running, not if it's actually working. A web server can be running but stuck in a deadlock, unable to serve requests. Health checks solve this by providing a deeper, application-aware signal of health, enabling true automated recovery.
The mental model
Think of Kubernetes as a manager talking to your application pod. It asks three questions. Liveness: "Are you okay? Should I restart you?" Readiness: "Are you ready for work? Should I send you users?" Startup: "Are you still getting ready? I'll wait before I start asking other questions." This prevents Kubernetes from killing a slow-booting app or sending traffic to one that's not ready.
How it works
Kubernetes periodically runs a "probe" against a container. There are three types of probes: Liveness, Readiness, and Startup. Each probe can be performed in one of three ways: an HTTP GET request to an endpoint (expecting a 2xx-3xx status), a TCP check on a port (seeing if it's open), or an Exec command run inside the container (expecting a zero exit code). If a probe fails a configured number of times, Kubernetes takes action: a failed Liveness probe restarts the container, while a failed Readiness probe removes it from the service load balancer until it passes again.
When to use it
Always use health probes for long-running services like APIs or web servers. Use a Readiness probe to prevent traffic during initialization, when loading data, or when temporarily busy. Use a Liveness probe to restart a container that has entered a deadlocked or unrecoverable state. Use a Startup probe for applications with a long startup time, to avoid them being killed by an aggressive Liveness probe before they are fully initialized.
When not to use it
Do not use a Liveness probe for tasks that run to completion and terminate, like a batch job. The biggest footgun is making a Liveness probe depend on external services (like a database). If the database is down, Kubernetes might restart all your app pods, causing a cascading failure. A probe should check the health of the container itself, not its dependencies.
One canonical example
A web application defines a Readiness probe on an HTTP endpoint /readyz. When deploying a new version, Kubernetes waits for this endpoint to return 200 OK before adding the new pod to the service's load balancer. It also has a Liveness probe on /healthz. If the app's memory leaks and it becomes unresponsive, the /healthz endpoint will stop responding, causing Kubernetes to restart the faulty container automatically.
Interview question
Which configuration mistake with a Kubernetes Liveness probe is explicitly warned against due to potential cascading failures?
- a.Using an Exec command that performs a computationally intensive task.
- b.Setting its initial delay too short for a slow-starting application.
- c.Relying on an external database's availability to determine container health.Correct
- d.Configuring it to check a different port than the main application traffic.
Why? this is the answer
The card states that 'The biggest footgun is making a Liveness probe depend on external services (like a database)' because it can lead to 'a cascading failure' by restarting all app pods unnecessarily. Other options describe less critical issues or valid practices.
Just read this? Test yourself on what you have been reading.
Read the original → kubernetes.io
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on kubernetes — each one lists the topics its interview covers.
See open roles