Courses Kubernetes fundamentalsConfiguring your app

Health checks

Liveness and readiness, gently.

Beginner10 min · lesson 13 of 24

In plain terms

Health checks are a nurse asking two questions: “are you alive?” (restart if not) and “ready for customers?” (hold the queue if not). Small checks that prevent big outages.

Health checks are how you tell Kubernetes whether your app is actually working, not just whether its process is running. They are the small addition that turns basic self-healing into reliable self-healing. Think of them as two questions Kubernetes asks your app: "are you alive?" and "are you ready for customers?"

Liveness and readiness

There are two main probes, and the difference matters. A liveness probe asks "is this app still alive, or has it hung?" — if it fails, Kubernetes restarts the container, which rescues an app that is stuck (frozen, deadlocked) even though its process is technically still running. A readiness probe asks "is this app ready to receive traffic right now?" — if it fails, Kubernetes stops sending requests to that pod (removes it from the Service) until it passes again, without restarting it. So liveness fixes a broken app by restarting it; readiness protects users by routing around a pod that is not ready (still starting up, or temporarily busy). A probe can be an HTTP request to a health endpoint, a TCP connection check, or a command run inside the container — whatever best reflects "is my app healthy?".

the two probes

spec:
  containers:
    - name: web
      image: my-app:1.4
      readinessProbe:               # "ready for traffic?" → if no, stop sending requests
        httpGet: { path: /ready, port: 8080 }
        initialDelaySeconds: 5
      livenessProbe:                # "still alive?" → if no, RESTART the container
        httpGet: { path: /healthz, port: 8080 }
        periodSeconds: 10
# readiness = route around a not-ready pod ; liveness = restart a hung one.

Why probes make everything safer

Probes are what let Kubernetes tell "running" from "working", and that distinction powers several things you have already met. During a rolling update, the new pods only count as ready when their readiness probe passes — so a broken new version stalls the rollout instead of replacing all your healthy pods (this is why the earlier lesson insisted on a readiness probe for safe releases). During normal operation, readiness keeps traffic away from pods that are still starting or briefly overloaded, so users do not hit errors. And liveness quietly restarts apps that have hung, healing failures that crash-detection alone would miss. A word of care: probes need to be set thoughtfully — a liveness probe that is too aggressive can restart a healthy-but-slow app in a loop, and one pointed at the wrong thing can cause needless restarts. But a sensible readiness probe (and usually a gentle liveness probe) on your apps is one of the highest-value habits in Kubernetes: it is the difference between an app that merely runs and one that Kubernetes can actually keep healthy and roll out safely.

What each probe does

Readiness routes traffic away from not-ready pods; liveness restarts hung ones. Probes let Kubernetes heal "up but broken" apps and roll out safely.

An over-aggressive liveness probe restarts healthy apps in a loop

If a liveness probe is too strict (short timeouts, no startup grace), it can fail during normal slow moments and restart a perfectly healthy app repeatedly, making things worse. Give probes sensible delays and thresholds, use a startup grace period for slow-booting apps, and prefer a solid readiness probe (safe, just routes traffic) while keeping liveness gentle and pointed at a genuine "am I hung?" signal.

Labels and selectorsConfigMaps: settings outside the…