derailed/k9s · warning

pod condition ready is false

Error message

pod condition ready is false

What it means

Pod.diagnose third gate: containers are all ready and gates satisfied, but the pod's aggregated Ready condition is still False. The kubelet derives Ready from readiness probes of every container plus gates, so this fires in the gap where the condition has not flipped (or a gate/probe oscillation set it false).

Source

Thrown at internal/render/pod.go:253

	ready := hasPodReadyCondition(st.Conditions)
	rgr, rgt := p.readinessGateStats(spec, &st)

	return p.diagnose(phase, cr, ct, ready, rgr, rgt)
}

func (*Pod) diagnose(phase string, cr, ct int, ready bool, rgr, rgt int) error {
	if phase == Completed {
		return nil
	}
	if cr != ct || ct == 0 {
		return fmt.Errorf("container ready check failed: %d of %d", cr, ct)
	}
	if rgt > 0 && rgr != rgt {
		return fmt.Errorf("readiness gate check failed: %d of %d", rgr, rgt)
	}
	if !ready {
		return fmt.Errorf("pod condition ready is false")
	}
	if phase == Terminating {
		return fmt.Errorf("pod is terminating")
	}

	return nil
}

// ----------------------------------------------------------------------------
// Helpers...

func asNominated(n string) string {
	if n == "" {
		return MissingValue
	}
	return n
}

View on GitHub (pinned to 2d3ccc6ba2)

Solutions

1. Re-check after a few seconds — usually a transient window
2. kubectl describe pod <name> and inspect the Ready condition's message/reason
3. Loosen probe thresholds (periodSeconds/failureThreshold) if the app is slow to stabilize
4. Stabilize the app's /health endpoint (remove external-call dependencies from probes)

Example fix

# before: probe fails on slow dependency
readinessProbe:
  httpGet: {path: /health, port: 8080}
  timeoutSeconds: 1
# after
readinessProbe:
  httpGet: {path: /health, port: 8080}
  timeoutSeconds: 3
  failureThreshold: 3

for _, c := range pod.Status.Conditions {
	if c.Type == v1.PodReady && c.Status == v1.ConditionTrue {
		// Ready-condition gate passes
	}
}

When it happens

Trigger: Viewing a pod in the seconds between last-probe success and kubelet updating the Ready condition; a container probe just failed and restarted; conditions flapping under load.

Common situations: Probes with tight timeouts under CPU-throttled pods; momentary 503s from the app's health endpoint; node-level kubelet lag on very busy nodes.

Related errors

• container ready check failed: %d of %d
• expecting Deployment resource
• expecting Pod resource
• container is not ready
• no node assigned

AI-assisted analysis of derailed/k9s@2d3ccc6ba2 (2026-08-15). Data as JSON: /api/errors/0e3105cc3327c667. Report an issue: GitHub.