Health Checks: Liveness & Readiness Probes
Configure liveness and readiness probes to ensure your applications are healthy and ready to serve traffic.
Health Checks: Liveness & Readiness Probes is a free DevOps Bootcamp lesson on CoddyKit — lesson 3 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the DevOps Bootcamp learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
Keeping Apps Healthy
How does Kubernetes know if your application is truly working? It's not enough for a container to just be running; it needs to be healthy and ready to serve traffic.
Kubernetes uses special checks called probes to monitor your applications. These probes help ensure your users always experience a reliable service.
What are Liveness Probes?
A Liveness Probe checks if your application is still alive and responsive. If a liveness probe fails, Kubernetes assumes your container is unhealthy and will restart it.
Think of it like a heartbeat monitor: if the heart stops, a restart is needed! This helps recover from deadlocks or application crashes.
Liveness Probe Basics
You can configure liveness probes using different methods:
- HTTP GET: Makes an HTTP request to a specified path.
- TCP Socket: Checks if a TCP connection can be opened to a port.
- Exec Command: Runs a command inside the container.
For web applications, HTTP GET is very common. Here's a snippet showing how you'd define one in a Pod's YAML:
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 5
periodSeconds: 5Liveness Probe in Action
This Python Flask app will simulate an unhealthy state by crashing after two requests to /healthz. The Kubernetes probe will detect this and restart the container.
First, save this as app.py:
from flask import Flask, Response
import os
import time
app = Flask(__name__)
request_count = 0
@app.route('/healthz')
def health_check():
global request_count
request_count += 1
if request_count > 2:
print("Liveness probe failing! Exiting...")
os._exit(1) # Simulate a crash
print(f"Liveness probe successful (count: {request_count})")
return Response("OK", status=200)
@app.route('/')
def home():
return "Hello from the Liveness Probe Demo!"
if __name__ == '__main__':
app.run(host='0.0.0.0', port=8080)Running Liveness Probe
Now, let's see how Kubernetes uses the liveness probe. If you deploy this with the following YAML, Kubernetes will restart the Pod when the health check fails:
apiVersion: v1
kind: Pod
metadata:
name: liveness-demo
spec:
containers:
- name: liveness-container
image: python:3.9-slim-buster
command: ["python", "app.py"]
ports:
- containerPort: 8080
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 5
periodSeconds: 5
failureThreshold: 1
volumeMounts:
- name: app-volume
mountPath: /app
volumes:
- name: app-volume
configMap:
name: liveness-app-config
# (You'd need a ConfigMap for app.py, omitted for brevity)When deployed, after 2 successful checks, the third check will fail, and Kubernetes will restart the container.
What are Readiness Probes?
A Readiness Probe checks if your application is ready to serve traffic. If a readiness probe fails, Kubernetes will stop sending traffic to that Pod, but it won't restart it.
This is crucial during startup (e.g., waiting for a database connection) or graceful shutdowns. Think: "Is the store open for customers?"
Readiness Probe Basics
Readiness probes are configured similarly to liveness probes, using HTTP GET, TCP Socket, or Exec commands. The key difference is their effect:
- Liveness: Restarts container on failure.
- Readiness: Removes Pod from service endpoints on failure (no traffic).
Here's a snippet for a readiness probe:
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 10
periodSeconds: 5Readiness Probe in Action
This Flask app simulates an application that takes some time to initialize (e.g., connecting to a database). It will only report "ready" after 5 seconds.
Save this as ready_app.py:
from flask import Flask, Response
import time
app = Flask(__name__)
start_time = time.time()
READY_AFTER_SECONDS = 5
@app.route('/ready')
def readiness_check():
if time.time() - start_time > READY_AFTER_SECONDS:
print("Readiness probe successful: App is ready!")
return Response("READY", status=200)
else:
print("Readiness probe failing: App not ready yet...")
return Response("NOT READY", status=503)
@app.route('/')
def home():
return "Hello from the Readiness Probe Demo!"
if __name__ == '__main__':
app.run(host='0.0.0.0', port=8080)Running Readiness Probe
When deployed with this YAML, the Pod won't receive traffic for the first initialDelaySeconds plus the time it takes for /ready to return 200 OK.
apiVersion: v1
kind: Pod
metadata:
name: readiness-demo
spec:
containers:
- name: readiness-container
image: python:3.9-slim-buster
command: ["python", "ready_app.py"]
ports:
- containerPort: 8080
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 10
periodSeconds: 3
volumeMounts:
- name: app-volume
mountPath: /app
volumes:
- name: app-volume
configMap:
name: readiness-app-config
# (You'd need a ConfigMap for ready_app.py, omitted for brevity)This ensures traffic only goes to truly ready instances.
Liveness vs. Readiness
It's important to use both probes correctly:
- Liveness Probe: Used to detect if your application has crashed or is in an unrecoverable state. If it fails, Kubernetes restarts the container.
- Readiness Probe: Used to detect if your application is ready to accept and process requests. If it fails, Kubernetes stops sending traffic to the Pod.
They serve different but complementary purposes to keep your applications robust.
Check Your Understanding
Which of the following statements about Liveness and Readiness Probes are TRUE?
Probes: Key Takeaways
In this lesson, you learned about Liveness and Readiness Probes in Kubernetes. These health checks are vital for maintaining the reliability and availability of your applications:
- Liveness Probes detect unhealthy containers and trigger restarts.
- Readiness Probes control when a Pod is ready to receive network traffic.
Using them effectively ensures your applications are always responsive and resilient to issues.
Frequently asked questions
Is the “Health Checks: Liveness & Readiness Probes” lesson free?
Yes — the full text of “Health Checks: Liveness & Readiness Probes” is free to read here on the web, and the DevOps Bootcamp course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the DevOps Bootcamp course, upgrade to CoddyKit PRO.
What will I learn in “Health Checks: Liveness & Readiness Probes”?
Configure liveness and readiness probes to ensure your applications are healthy and ready to serve traffic. You practise DevOps Bootcamp with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start DevOps Bootcamp?
No prior experience is required. DevOps Bootcamp on CoddyKit is structured for beginners through advanced learners; this is — lesson 3 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “Health Checks: Liveness & Readiness Probes” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this DevOps Bootcamp lesson?
Yes. Every DevOps Bootcamp lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.
All lessons in this course
- Logging with kubectl logs
- Metrics with Prometheus & Grafana
- Health Checks: Liveness & Readiness Probes
- Distributed Tracing and Events