How to fix waiting for ordinal not yet ready in Kubernetes

KubernetesINTERMEDIATEMEDIUMUpdated Dec 6, 2025· 155 views

In Kubernetes StatefulSets with OrderedReady pod management policy, pods are created sequentially and each pod must reach Ready state before the next one is scheduled. The "waiting for ordinal not yet ready" condition occurs when a pod cannot achieve Ready state, blocking subsequent pods from starting.

Quick fix

Fixes waiting for ordinal not yet ready

kubectl get pods -n <namespace> -l app=<statefulset-name>
  1. Identify which pod is stuck and not reaching Ready state
  2. Check logs of the blocking pod
  3. Verify readiness probe configuration
  4. Check if the blocking pod is running but not healthy
kubernetes — error
kubectl get pods -n <namespace> -l app=<statefulset-name>
waiting for ordinal not yet ready

What this error means

StatefulSets with the default OrderedReady pod management policy enforce strict ordering: pods are created in ordinal order (pod-0, pod-1, pod-2, etc.), and each pod must pass all readiness checks before the next one begins initializing. When a pod gets stuck (not becoming Ready), the entire StatefulSet deployment stalls. A pod is considered "Ready" when: (1) all containers are running, (2) any readiness probes defined in the container spec return success, and (3) the pod's status condition transitions to Ready. If any of these conditions fail to materialize, subsequent pods wait indefinitely and the StatefulSet cannot scale up.

Typical symptoms

  • Pods 0 and 1 are running, but pods 2, 3, etc. remain in "Pending" state
  • kubectl describe on later pods shows "waiting for ordinal not yet ready" message
  • Earlier ordinal pods show "Ready 1/1" but have failing readiness probes
  • StatefulSet remains incomplete: "1/3 ready" or "2/5 ready" for extended periods
  • Scaling operations fail to complete because new replicas cannot start
  • Application-dependent pods (like cache nodes) fail to initialize due to missing dependencies
  • Helm releases or deployments timeout waiting for StatefulSet to reach desired replicas

Common causes

  1. Readiness probe misconfiguration (wrong endpoint, port, or initial delay too short)
  2. Earlier ordinal pod failing its readiness check (crashing, hanging, or probe timeout)
  3. Container image not pulling successfully on later pods
  4. Insufficient CPU or memory resources preventing pod scheduling
  5. Init container in the pod failing or hanging indefinitely
  6. Network connectivity issues between pods (DNS, service discovery, inter-pod communication)
  7. Application startup logic waiting for earlier pods to be fully healthy (but incorrectly detecting readiness)
  8. Volume mounting failures (PVC not binding, storage class misconfiguration)

How to fix "waiting for ordinal not yet ready"

1Identify which pod is stuck and not reaching Ready state

List all pods in the StatefulSet:

bash
kubectl get pods -n <namespace> -l app=<statefulset-name>

Look for the pod with the highest ordinal that is not Ready. Check its status in detail:

bash
kubectl describe pod <statefulset-name>-<ordinal> -n <namespace>

Note the conditions section and recent events. The "Waiting for ordinal" message comes from a later pod; find the actual pod that cannot transition to Ready by looking at earlier ordinals.

2Check logs of the blocking pod

Examine the logs of the pod preventing others from starting:

bash
kubectl logs <statefulset-name>-0 -n <namespace>  # Check pod-0 if it's blocking
kubectl logs <statefulset-name>-0 -n <namespace> --all-containers=true  # Include init containers
kubectl logs <statefulset-name>-0 -n <namespace> --previous  # If pod crashed and restarted

Look for error messages, exceptions, or timeouts. Common patterns:
- "Connection refused" (service not ready)
- "Timeout" (waiting for dependency)
- Application startup errors
- "OOMKilled" or "Evicted" (resource issues)

3Verify readiness probe configuration

Check the StatefulSet definition for readiness probes:

bash
kubectl get statefulset <statefulset-name> -n <namespace> -o yaml | grep -A 10 "readinessProbe"

Common issues:
- initialDelaySeconds too short for app startup time
- Wrong path, port, or scheme for the probe endpoint
- timeoutSeconds too aggressive (default 1s)
- Readiness endpoint returning error due to missing dependencies

Example fix in StatefulSet manifest:

yaml
readinessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 30  # Give app time to start
  periodSeconds: 5
  timeoutSeconds: 2

Apply changes:

bash
kubectl apply -f statefulset.yaml
4Check if the blocking pod is running but not healthy

Get the full pod status:

bash
kubectl get pod <statefulset-name>-0 -n <namespace> -o wide
kubectl get pod <statefulset-name>-0 -n <namespace> -o jsonpath="{.status}"

Look for:
- Container ready: "ContainerReady=True" vs "False"
- Ready condition: "Ready=True" vs "False"
- Actual error in containerStatuses section

Test the readiness endpoint manually if pod is running:

bash
kubectl exec -it <statefulset-name>-0 -n <namespace> -- curl -v http://localhost:8080/health

If this fails, the application isn't responding correctly to readiness checks.

5Verify init containers complete successfully

If the StatefulSet uses init containers, check their status:

bash
kubectl describe pod <statefulset-name>-0 -n <namespace>

Look for "Init Containers" section. Each must show "State: Terminated" with "Exit Code: 0". If stuck:

bash
kubectl logs <statefulset-name>-0 -n <namespace> -c <init-container-name>

Common init container issues:
- Downloading configuration files that don't exist
- Waiting for DNS names that haven't resolved
- Network calls timing out

Increase timeouts or fix the network issue, then delete the pod to restart:

bash
kubectl delete pod <statefulset-name>-0 -n <namespace>
6Check resource constraints and scheduling issues

Verify the pod can be scheduled:

bash
kubectl describe pod <statefulset-name>-0 -n <namespace> | grep -A 5 "Events"

If you see "Pending" with event "insufficient cpu" or "insufficient memory", check resource requests:

bash
kubectl describe statefulset <statefulset-name> -n <namespace> | grep -A 20 "Limits\|Requests"

Check node capacity:

bash
kubectl describe nodes
kubectl top nodes  # Requires metrics-server

If resource-constrained, either add more nodes or reduce pod requests:

yaml
resources:
  requests:
    memory: "256Mi"
    cpu: "100m"
  limits:
    memory: "512Mi"
    cpu: "500m"
7Check inter-pod dependencies and network connectivity

If pods need to communicate (e.g., database cluster setup), verify connectivity:

bash
kubectl exec -it <statefulset-name>-1 -n <namespace> -- /bin/bash
# Inside pod, test connection to earlier pod:
nslookup <statefulset-name>-0.<headless-service-name>.<namespace>.svc.cluster.local
telnet <statefulset-name>-0.<headless-service-name>.<namespace>.svc.cluster.local 5432  # For database

Verify headless Service exists and targets the StatefulSet:

bash
kubectl get svc <headless-service-name> -n <namespace> -o yaml
kubectl get endpoints <headless-service-name> -n <namespace>

If DNS or connectivity fails, check CNI plugin and network policies:

bash
kubectl get pods -n kube-system -l tier=cni  # Check CNI pods
kubectl get networkpolicies -n <namespace>
8Increase readiness check tolerances as a temporary measure

If the blocking pod is slow but eventually becomes healthy, temporarily relax readiness requirements:

bash
kubectl patch statefulset <statefulset-name> -n <namespace> -p '{"spec": {"template": {"spec": {"containers": [{"name": "<container-name>", "readinessProbe": {"initialDelaySeconds": 60, "timeoutSeconds": 5, "periodSeconds": 10}}]}}}}'

Or edit directly:

bash
kubectl edit statefulset <statefulset-name> -n <namespace>

Increase initialDelaySeconds and timeoutSeconds. This is temporary; investigate root cause in parallel.

9Switch to Parallel pod management policy if ordering not required

If strict pod ordering isn't necessary for your application, change to Parallel policy:

bash
kubectl patch statefulset <statefulset-name> -n <namespace> -p '{"spec": {"podManagementPolicy": "Parallel"}}'

With Parallel, all pods start simultaneously regardless of Ready state. Useful for stateless workloads or when pod dependencies are handled by the application, not Kubernetes.

Modify manifest:

yaml
spec:
  podManagementPolicy: Parallel
  # ... rest of spec

Warning: Use only if your application doesn't require strict initialization ordering. Most stateful databases (MySQL, PostgreSQL, Cassandra, etc.) require OrderedReady.

Advanced notes

In production StatefulSets, the initialization order is critical for stateful applications. Databases like MySQL (with Percona XtraDB) expect ordinal-0 to be the primary and ordinal-1+ to join as replicas. If you have a custom readiness endpoint, ensure it correctly reports readiness—a common pitfall is reporting "ready" before dependencies (like initialization scripts or cluster bootstrapping) complete. For distributed systems, use initialDelaySeconds that accounts for your slowest startup scenario plus 10-20% buffer. In CI/CD pipelines, Helm or ArgoCD may timeout waiting for StatefulSets; adjust helm install --timeout and ArgoCD syncPolicy.syncOptions to increase wait times. Pod disruption budgets (PDB) can also interact with this: if a PDB is too restrictive, pod eviction during maintenance may fail, blocking the entire StatefulSet. Finally, consider using StatefulSet lifecycle hooks (postStart, preStop) for coordination between pods rather than relying solely on readiness probes.

Frequently asked questions

What does "waiting for ordinal not yet ready" mean?
), and each pod must pass all readiness checks before the next one begins initializing. When a pod gets stuck (not becoming Ready), the entire StatefulSet deployment stalls. A pod is considered "Ready" when: (1) all containers are running, (2) any readiness probes defined in the container spec return success, and (3) the pod's status condition transitions to Ready.
How do I fix "waiting for ordinal not yet ready"?
In Kubernetes StatefulSets with OrderedReady pod management policy, pods are created sequentially and each pod must reach Ready state before the next one is scheduled. The "waiting for ordinal not yet ready" condition occurs when a pod cannot achieve Ready state, blocking subsequent pods from starting.
What causes "waiting for ordinal not yet ready"?
Readiness probe misconfiguration (wrong endpoint, port, or initial delay too short) Earlier ordinal pod failing its readiness check (crashing, hanging, or probe timeout) Container image not pulling successfully on later pods
Is the "waiting for ordinal not yet ready" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading