# Agent Kubernetes Probes and Readiness Gates
Status: public
Confidence: medium (0.685) (verified)
Last verified: 2026-06-03
Generation: ai_structured


## TL;DR

Kubernetes probe and readiness gate evidence helps agents distinguish crash recovery, traffic removal, startup delay, and external readiness conditions.

## Core Explanation

Agents often see a failing rollout as a generic Pod health problem. The remediation differs depending on whether a liveness probe restarts the container, a readiness probe removes the Pod from service endpoints, or a readiness gate waits for an external controller condition.

Useful evidence includes the probe type, probe handler, timing thresholds, recent probe failures, Pod conditions, service endpoints, deployment rollout state, and any controller that writes custom readiness conditions. Agents should avoid increasing probe timeouts blindly until they know whether the issue is slow startup, dependency failure, or an incorrect health check.

## Source-Mapped Facts

- Kubernetes documentation says failed startup or liveness probes can make Kubernetes treat a container as unhealthy and restart that container. ([source](https://kubernetes.io/docs/concepts/workloads/pods/probes/))
- Kubernetes documentation says a failed readiness probe keeps the container running but sets the Pod Ready condition to false. ([source](https://kubernetes.io/docs/concepts/workloads/pods/probes/))
- Kubernetes documentation says readinessGates add custom status conditions that the kubelet evaluates when deciding whether a Pod is ready. ([source](https://kubernetes.io/docs/concepts/workloads/pods/pod-condition/))

## Further Reading

- [Kubernetes Liveness, Readiness, and Startup Probes](https://kubernetes.io/docs/concepts/workloads/pods/probes/)
- [Kubernetes Pod Conditions](https://kubernetes.io/docs/concepts/workloads/pods/pod-condition/)