What causes "desiring %d replicas got %d available" in derailed/k9s?

If mid-deploy: kubectl rollout status deploy/ and wait — it self-clears

desiring %d replicas got %d available

Error message

desiring %d replicas got %d available

What it means

Deployment.diagnose compares status.replicas (desired) with status.availableReplicas; any difference yields 'desiring N replicas got M available'. It is the rollout-health indicator behind the deployment row status, red mid-rollout or when pods cannot become available.

Source

Thrown at internal/render/dp.go:109

	r.ID = client.MetaFQN(&dp.ObjectMeta)
	r.Fields = model1.Fields{
		dp.Namespace,
		dp.Name,
		computeVulScore(dp.Namespace, dp.Labels, &dp.Spec.Template.Spec),
		strconv.Itoa(int(dp.Status.AvailableReplicas)) + "/" + strconv.Itoa(int(desired)),
		strconv.Itoa(int(dp.Status.UpdatedReplicas)),
		strconv.Itoa(int(dp.Status.AvailableReplicas)),
		mapToStr(dp.Labels),
		AsStatus(d.diagnose(dp.Status.Replicas, dp.Status.AvailableReplicas)),
		ToAge(dp.GetCreationTimestamp()),
	}

	return nil
}

func (Deployment) diagnose(desired, avail int32) error {
	if desired != avail {
		return fmt.Errorf("desiring %d replicas got %d available", desired, avail)
	}

	return nil
}

View on GitHub (pinned to 2d3ccc6ba2)

Solutions

If mid-deploy: kubectl rollout status deploy/<name> and wait — it self-clears
If stuck: kubectl get events and kubectl describe deploy <name> to find the blocker
Check pods: kubectl get pods -l <selector> for CrashLoop/ImagePull/Pending and fix the root cause (image, probe, resources)
Verify quotas/PDBs are not blocking scale (kubectl describe resourcequota / pdb)

Example fix

# before: ready probe too strict, available stays 0/2
readinessProbe:
  httpGet: {path: /healthz, port: 8080}
  initialDelaySeconds: 0
  failureThreshold: 1
# after
readinessProbe:
  httpGet: {path: /healthz, port: 8080}
  initialDelaySeconds: 10
  failureThreshold: 3

Defensive patterns

Strategy: fallback

Validate before calling

if dp.Status.Replicas == dp.Status.AvailableReplicas {
	status = "ok" // skip diagnose
}

Try / catch

Treat the diagnose error as row status, not a control-flow failure; pair it with kubectl rollout status in CI to distinguish transient rollouts from stuck ones.

Prevention

Make readiness probes fast and accurate so rollouts converge
Size resources/quotas for the replica count you request
Alert on stuck rollouts (availableReplicas unchanged for N minutes), not on every mismatch

When it happens

Trigger: kubectl apply of a new image while pods restart; HPA scaling up faster than pods pass readiness; pods CrashLooping/ImagePullBackOff so availableReplicas never catches up; rollout stuck on PDB/quota.

Common situations: Normal deploys (transient), insufficient resources or node pressure, bad probes failing readiness, quota exhaustion, node taints preventing scheduling.

Related errors

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