Kubernetes readiness: fix a failing HTTP probe

Separate running, ready, and restarting

Read the Pod’s Ready condition and the affected container’s readiness and restart count. A running process can fail a readiness check repeatedly without being restarted by that check. That distinction matters when the application appears healthy from a terminal.

In our test, /wrong consistently returned 404. The container remained running with zero restarts, but its endpoint was marked not ready and a request through the Service failed. The missing traffic was explained by readiness rather than a crash loop.

sh · EXAMPLE

kubectl -n your-namespace describe pod your-pod
kubectl -n your-namespace get pod your-pod -o yaml
kubectl -n your-namespace get endpointslices \
  -l kubernetes.io/service-name=your-service -o yaml

Read the actual probe definition

Check httpGet.path, port, scheme, timing, and any required headers. Confirm which container owns the probe and which socket serves that URL. A valid public route may differ from the direct application route used by the kubelet.

Do not assume an ingress rewrite or authentication middleware applies the same way to a direct Pod request. In our minimal server /ready was the intended contract; /wrong was simply nonexistent. There was no downstream outage or delayed startup to wait out.

Verify the endpoint before changing the probe

Inspect application startup output and request the intended endpoint from an appropriate diagnostic context. If the readiness response is intentionally reporting an unavailable dependency, repair that dependency rather than replacing the check with an unrelated successful page.

The lab’s corrected probe used the existing /ready endpoint on port 8080. This container fragment shows the change; the interval and threshold are short lab settings, not defaults recommended for every service.

yaml · EXAMPLE

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  periodSeconds: 1
  failureThreshold: 1

Update the template and verify the Service path

Apply the correction to the owning workload’s Pod template through the normal delivery flow. Check the replacement Pods and EndpointSlices after the change. A configured readiness URL is not evidence until the observed probe succeeds.

Our corrected test Pod became Ready, and the same Service request returned HTTP 200 with the application marker after its backend changed to the ready Pod. We verified the complete request path rather than declaring success from the manifest alone.

sh · EXAMPLE

kubectl -n your-namespace rollout status deployment/your-deployment
kubectl -n your-namespace get pods
kubectl -n your-namespace get endpointslices \
  -l kubernetes.io/service-name=your-service -o yaml

Keep the readiness contract meaningful

Removing the probe may make the status look better while sending traffic to an application that cannot serve it. Decide what this service must be able to do before it accepts requests, and make the readiness endpoint represent that contract.

If the endpoint now succeeds but traffic still fails, continue with selector, targetPort, network policy, and the client request. Restored readiness narrows the investigation; it does not certify the entire application or every dependency.

Know the limits

Reproduced in Kubernetes v1.32.2 with an HTTP application that serves /ready but returns 404 for /wrong. The lab uses an ordinary Service without publishNotReadyAddresses and no liveness or startup probe. Zero restarts in this case is expected, not proof of successful readiness.

Sources & further reading

A technical publication by CoreTrailKit.

Browse all articles