What causes "mismatch desired(%d) vs ready(%d)" in derailed/k9s?

Run kubectl describe rs and read Events for pod failures

mismatch desired(%d) vs ready(%d)

Error message

mismatch desired(%d) vs ready(%d)

What it means

ReplicaSet.diagnose compares rs.Status.Replicas with rs.Status.ReadyReplicas; when they differ (and replicas>0) it returns 'mismatch desired(N) vs ready(M)', rendered into the VALID column by AsStatus. 'desired' here is the current replica count, so the message means the RS has pods that are created but not ready. It is a workload health signal, not a rendering error, and it never escapes Render.

Source

Thrown at internal/render/rs.go:104

		strconv.Itoa(int(*rs.Spec.Replicas)),
		strconv.Itoa(int(rs.Status.Replicas)),
		strconv.Itoa(int(rs.Status.ReadyReplicas)),
		strings.Join(cos, ","),
		strings.Join(imgs, ","),
		mapToStr(rs.Labels),
		AsStatus(r.diagnose(&rs)),
		ToAge(rs.GetCreationTimestamp()),
	}

	return nil
}

func (ReplicaSet) diagnose(rs *appsv1.ReplicaSet) error {
	if rs.Status.Replicas != rs.Status.ReadyReplicas {
		if rs.Status.Replicas == 0 {
			return fmt.Errorf("did not phase down correctly expecting 0 replicas but got %d", rs.Status.ReadyReplicas)
		}
		return fmt.Errorf("mismatch desired(%d) vs ready(%d)", rs.Status.Replicas, rs.Status.ReadyReplicas)
	}

	return nil
}

View on GitHub (pinned to 2d3ccc6ba2)

Solutions

Run kubectl describe rs <name> and read Events for pod failures
Inspect unready pods (kubectl get pods -l <selector>, then describe) for the exact reason
Fix the root cause: image, resources, probes, or scheduling constraints
If mid-rollout, wait with kubectl rollout status rs/<name>

Example fix

# before: desired 2, ready 0 — pods in ImagePullBackOff
kubectl get pods -l app=myrs
# after: correct the image and let it roll
kubectl set image rs/myrs app=repo/app:fixed-tag
kubectl rollout status rs/myrs

Defensive patterns

Strategy: validation

Validate before calling

# catch the condition before it renders
kubectl get rs -o json | jq '.items[] | select(.status.replicas != .status.readyReplicas) | {name:.metadata.name, replicas:.status.replicas, ready:.status.readyReplicas}'

Prevention

Watch rollout completion with kubectl rollout status instead of eyeballing counts
Keep readiness probes, image tags, and resource requests correct so pods go ready
Run kubectl describe rs and pod events at the first VALID-column mismatch
Treat the message as workload health, not a UI failure

When it happens

Trigger: Pods stuck unready: CrashLoopBackOff, ImagePullBackOff, insufficient CPU/memory, Pending on an unschedulable node, PDB or taint blocks; viewing the RS view mid-rollout while replacement pods start.

Common situations: Bad image tag or missing registry credentials; resource quotas exhausted; node pressure; rolling updates observed mid-progress; failing readiness probes.

Related errors

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