Liveness and readiness probes configured for all Deployments
Why it matters
Without liveness and readiness probes, Kubernetes has no signal about whether your application is healthy — it routes traffic to pods that are stuck in initialization, deadlocked, or silently broken, and it never restarts containers that have reached a bad state without crashing (CIS Kubernetes 5.5.1). Probes with unrealistic thresholds (timeoutSeconds exceeding periodSeconds) guarantee probes always fail, defeating their purpose. A missing readiness probe means traffic arrives before the application finishes startup, producing a burst of 502 errors that users experience as downtime.
Severity rationale
Low because missing probes degrade availability and mask application failures, but do not directly expose data or allow unauthorized access.
Remediation
Add both livenessProbe and readinessProbe to every container in your Deployment manifests. The liveness probe restarts unhealthy containers; the readiness probe gates traffic routing:
containers:
- name: app
livenessProbe:
httpGet:
path: /health/live
port: 8080
initialDelaySeconds: 15
periodSeconds: 15
timeoutSeconds: 3
failureThreshold: 3
readinessProbe:
httpGet:
path: /health/ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 5
timeoutSeconds: 1
failureThreshold: 2
Implement /health/live as a shallow ping (returns 200 if the process is alive) and /health/ready as a deeper check that verifies database connectivity and any required upstream dependencies.
Detection
-
ID:
probes-configured -
Severity:
low -
What to look for: Count all Deployment and StatefulSet resources. For each, check whether both livenessProbe and readinessProbe are configured on every container. Verify probe values are sensible:
timeoutSecondsmust be less thanperiodSeconds, andfailureThresholdshould be at least 2. Report the ratio of properly-configured probes. -
Pass criteria: Every Deployment and StatefulSet includes both livenessProbe and readinessProbe on all containers, with
initialDelaySecondsof at least 5,timeoutSecondsunderperiodSeconds, andfailureThresholdof at least 2. Report: "X of Y Deployments have both probes configured with valid thresholds." -
Fail criteria: Any Deployment or StatefulSet is missing livenessProbe or readinessProbe, or probes are configured with unrealistic values (e.g., timeout exceeds period, failure threshold of 1).
-
Do NOT pass when: Probes are defined but point to non-existent endpoints or use TCP probes on HTTP services where an HTTP health endpoint should be used instead.
-
Skip (N/A) when: The project has no Kubernetes Deployments, or uses serverless/managed functions.
-
Detail on fail: Quote the Deployment name and missing probe. Example:
"Deployment 'app' lacks readinessProbe. Pod is marked ready before application initialization completes."or"Liveness probe timeout is 30s, period is 10s — probe may never complete" -
Remediation: Add probes to your Deployment:
livenessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 10 periodSeconds: 10 timeoutSeconds: 2 failureThreshold: 3 readinessProbe: httpGet: path: /ready port: 8080 initialDelaySeconds: 5 periodSeconds: 5 timeoutSeconds: 1 failureThreshold: 2
External references
- iso-25010:2011 · reliability-availability — Reliability / Availability
- external · CIS-Kubernetes-5.5.1 — CIS Kubernetes Benchmark §5.5.1 — Configure Image Provenance using ImagePolicyWebhook
Taxons
History
- 2026-04-18·v1.0.0·Initial import from infrastructure-hardening·automated