Deployments, StatefulSets and DaemonSets with a container that has no readiness probe

Traffic arrives before the app is ready

Readiness is what connects a pod to its Service. The probes documentation explains that readiness probes decide when a container can accept traffic, which matters while an app opens connections, loads files or warms caches, and again later when it recovers from a temporary overload. When a readiness probe fails, the EndpointSlice controller removes the pod’s IP from every matching Service.

With no probe, there is nothing to fail. The kubelet treats an absent probe as a success, so the pod is added to the Service the moment its containers start. The first requests after every rollout, scale-up or reschedule hit a process that cannot answer yet, and users see errors. A rolling update makes this worse, because Kubernetes moves on to replace the next old pod as soon as the new one reports ready.

Listing containers without readiness checks

kubectl get deployments,statefulsets,daemonsets -A -o json | jq -r '
  .items[] | .kind as $k | .metadata as $m
  | .spec.template.spec.containers[]
  | select(.readinessProbe == null)
  | "\($k) \($m.namespace)/\($m.name) \(.name)"'

Filter the output to workloads that sit behind a Service to see where it matters most.

How the check decides

ZopNight looks at the main containers in each workload template and raises the recommendation as soon as one of them lacks a readiness probe. The recommendation is per workload and does not list container names. It applies to Deployments, StatefulSets and DaemonSets on EKS, GKE and AKS, and it has no threshold or window beyond the presence of the probe.

Where it is less useful

Init containers are never checked. The rule does not know whether a workload is behind a Service, so background workers and DaemonSet agents that serve no requests are flagged too. A workload with no containers listed is skipped. Pods that do have readiness probes but keep failing them show up instead as Deployment not fully ready. The restart side of health checking is Missing liveness probe.

Error spikes, not dollars

This medium-severity reliability recommendation carries no savings figure. Its cost is failed requests during every deploy and scale event.

Gating traffic on real readiness

1. Add an endpoint that returns success only after startup work is finished.
2. Configure the probe on each serving container, for example an httpGet or a tcpSocket check with periodSeconds: 10.
3. Unlike liveness, a readiness check may reasonably include critical dependencies, since failing it only removes the pod from the Service.
4. Roll the workload and watch kubectl get endpointslices -l kubernetes.io/service-name=<svc> to confirm new pods join only once ready.