cilium/cilium · warning

%d endpoints are not ready

Error message

%d endpoints are not ready

What it means

Aggregated warning from parseEndpointsResponse (cilium-cli/status/status.go:287) emitted when one or more Cilium endpoints on a node are not in the Ready state. The CLI counts endpoints whose Status.State is nil or != EndpointStateReady and reports the count. This means workloads are up but their networking is not fully provisioned (identity not resolved, BPF program not regenerated, or endpoint in a fail/locked state).

Source

Thrown at cilium-cli/status/status.go:287

	}
}

func (s *Status) parseEndpointsResponse(deployment, podName string, eps []*models.Endpoint, err error) {
	if err != nil {
		s.AddAggregatedError(deployment, podName, fmt.Errorf("unable to retrieve cilium endpoint information: %w", err))
		return
	}

	var notReady uint
	for _, ep := range eps {
		if ep != nil && ep.Status != nil && ep.Status.State != nil &&
			*ep.Status.State != models.EndpointStateReady {
			notReady++
		}
	}

	if notReady > 0 {
		s.AddAggregatedWarning(deployment, podName, fmt.Errorf("%d endpoints are not ready", notReady))
	}
}

func (s *Status) statusSummary(name string) (text string) {
	var errors, warnings int
	if a := s.Errors[name]; a != nil {
		var disabled bool
		for _, c := range a {
			errors += len(c.Errors)
			warnings += len(c.Warnings)

			if c.Disabled {
				disabled = true
			}
		}

		var s []string
		if errors > 0 {

View on GitHub (pinned to ac7b90affa)

Solutions

1. Wait briefly — endpoints transitioning to Ready during rollouts is normal; re-run `cilium status` to confirm it clears.
2. List unready endpoints: `kubectl get ciliumendpoints -A` and check their state/status fields.
3. If stuck, check agent logs for identity/regeneration failures and verify kvstore/etcd health, which commonly blocks identity resolution.
4. Restart the affected endpoint's pod or the agent pod to force re-provisioning if regeneration is wedged.

Example fix

// before
cilium status
// 3 endpoints are not ready
// after: identify which and why
kubectl get ciliumendpoints -A -o wide
kubectl -n kube-system logs -l k8s-app=cilium --tail=200 | grep -i 'endpoint.*regenerat'

for _, ep := range eps {
  if ep == nil || ep.Status == nil || ep.Status.State == nil || *ep.Status.State != models.EndpointStateReady {
    unready++
  }
}
if unready > 0 { /* defer dependent actions until endpoints converge */ }

func endpointReady(ep *models.Endpoint) bool {
  return ep != nil && ep.Status != nil && ep.Status.State != nil &&
    *ep.Status.State == models.EndpointStateReady
}

When it happens

Trigger: parseEndpointsResponse counts eps where ep.Status.State is nil or != "ready" and notReady > 0, producing '%d endpoints are not ready' as a warning for that pod.

Common situations: New pods still initializing during large scale-out, endpoints stuck in 'waiting-for-identity' when the kvstore/identity allocation is slow, 'regenerating' loops from bad NetworkPolicy, terminating pods during rollout, or nodes under CPU pressure delaying BPF compilation.

Related errors

• api not ready
• %d %s are not ready
• unable to retrieve cilium endpoint information: %w
• failed to create or update Endpoints: %w
• status.Status

AI-assisted analysis of cilium/cilium@ac7b90affa (2026-08-31). Data as JSON: /api/errors/af12d4f578fcc93d. Report an issue: GitHub.