# Missing Readiness Probe

> Without a readiness probe Kubernetes adds a pod to Service endpoints as soon as its container starts, before the application can serve. Every rollout then drops requests during the warm-up window. ZopNight checks 3 workload kinds; there is no metric, only the spec.

Source: https://zop.dev/integrations/kubernetes/recommendations/missing-readiness-probe
Updated: 2026-08-19

---

## Started is not the same as ready

The moment a container process starts, the pod is added to its Service's EndpointSlice and begins
receiving traffic. That happens whether or not the application has loaded configuration, warmed a
cache, established a connection pool or bound its listener.

For an application that starts in milliseconds the gap does not matter. For a JVM service, a
framework with heavy initialisation, or anything that pre-loads data, the gap is seconds, and
every request arriving in it fails.

## Rollouts are where this actually bites

During a rolling update Kubernetes replaces pods in batches. With no readiness probe it considers
each new pod available immediately and proceeds to terminate the next old one.

The result is a rollout that reports success while dropping a slice of traffic at every step. It
is intermittent, brief, and looks like a network blip rather than a deploy problem. That is why
it survives so many deployments before anyone traces it.

## What a good readiness check tests

Unlike liveness, readiness **should** consider dependencies. A pod that cannot reach its database
genuinely should not receive traffic, and removing it from the endpoint pool is exactly right.

The failure is recoverable: the pod stays alive, keeps being probed, and rejoins when the check
passes. Nothing restarts.

## Readiness also gates disruption

`kubectl drain` and the eviction API respect readiness through PodDisruptionBudgets. A workload
with no readiness probe reports every pod as ready the instant it starts, so a budget requiring
"at least 2 available" can be satisfied by two pods that cannot serve, and the drain proceeds
into an outage.

## Selecting containers where readinessProbe is null

```bash
kubectl get deploy,statefulset,daemonset -A -o json | jq -r '
  .items[] | . as $w | .spec.template.spec.containers[]
  | select(.readinessProbe == null)
  | "\($w.kind) \($w.metadata.namespace)/\($w.metadata.name): \(.name)"'
```

## Where it matters least

A DaemonSet with no Service in front of it, or a worker consuming from a queue rather than
serving requests, has no endpoint pool to be added to. The probe adds little there, and this
finding can reasonably be dismissed for those workloads.