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

Compare READY vs DESIRED (kubectl get sts ), then kubectl rollout status sts/

want %d replicas got %d available

Error message

want %d replicas got %d available

What it means

StatefulSet.diagnose's second check fires when desired (spec.replicas) != ready (status.readyReplicas) and returns 'want D replicas got R available', shown by AsStatus in the VALID column. It means the StatefulSet has not converged to its configured replica count — scale-up in progress, blocked provisioning, or stuck pods. It is status text only and never propagates as a Render error.

Source

Thrown at internal/render/sts.go:93

		strconv.Itoa(int(sts.Status.ReadyReplicas)) + "/" + strconv.Itoa(int(desired)),
		asSelector(sts.Spec.Selector),
		na(sts.Spec.ServiceName),
		podContainerNames(&sts.Spec.Template.Spec, true),
		podImageNames(&sts.Spec.Template.Spec, true),
		mapToStr(sts.Labels),
		AsStatus(s.diagnose(desired, sts.Status.Replicas, sts.Status.ReadyReplicas)),
		ToAge(sts.GetCreationTimestamp()),
	}

	return nil
}

func (StatefulSet) diagnose(d, c, r int32) error {
	if c != r {
		return fmt.Errorf("desired %d replicas got %d available", c, r)
	}
	if d != r {
		return fmt.Errorf("want %d replicas got %d available", d, r)
	}

	return nil
}

View on GitHub (pinned to 2d3ccc6ba2)

Solutions

Compare READY vs DESIRED (kubectl get sts <name>), then kubectl rollout status sts/<name>
Describe the highest not-yet-ready ordinals to find the blocker
Verify StorageClass capacity and PVC binding for the new ordinals
If the desired count is wrong, scale back with kubectl scale sts/<name> --replicas=<n>

Example fix

# before: want 5 got 3 — new ordinals pending
kubectl scale sts/mysts --replicas=5
kubectl rollout status sts/mysts
# after: converge to 5, or set the reachable target
kubectl scale sts/mysts --replicas=3

Defensive patterns

Strategy: validation

Validate before calling

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

Prevention

After scaling, wait with kubectl rollout status sts/<name> instead of reading raw counts
Verify StorageClass capacity and PVC binding can satisfy new ordinals before scaling up
Keep readiness probes realistic so new pods converge promptly
Treat the message as convergence state; act on the workload, not the renderer

When it happens

Trigger: After kubectl scale sts or a manifest change raising spec.replicas before new pods become ready; pods blocked by unavailable storage, scheduling, or failing readiness probes; scale-down with terminating pods still counted.

Common situations: Autoscaler raising STS replicas; StorageClass capacity limits; OrderedReady pods blocked on an earlier ordinal; rolling updates viewed mid-flight.

Related errors

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