# Kubernetes Deployment rollout stuck: ProgressDeadlineExceeded The Deployment made no progress for progressDeadlineSeconds (600 by default), so the controller set Progressing to False with reason ProgressDeadlineExceeded. The condition is a report, not an intervention — Kubernetes keeps retrying and never rolls back on its own. The blocker is in the newest ReplicaSet's pods. > Confidence: high · Verified: 2026-08-11 · Status: fresh · Source: https://knowbase.sh/k/kubernetes-deployment-progressdeadlineexceeded ## Error signature ``` ProgressDeadlineExceeded ``` Codes: ProgressDeadlineExceeded, ReplicaSetCreateError ## Problem kubectl rollout status sits on 'Waiting for rollout to finish' and eventually exits 1 with 'error: deployment exceeded its progress deadline'. The Deployment's Progressing condition is False with reason ProgressDeadlineExceeded. Old pods are usually still serving traffic, so nothing pages — but the new version never arrives, and the condition itself never says why. Progress, for a Deployment, means concrete events: a new ReplicaSet created, the newest one scaling up, old ones scaling down, or new pods becoming ready. If none of those happens for progressDeadlineSeconds, the deadline fires; the actual blocker is a level down, in the pods of the newest ReplicaSet. ## Root cause - **New pods never become Ready because the readiness probe fails** _(primary)_ - The container starts but its readiness probe never succeeds — wrong port or path, a dependency the new version cannot reach, or an app that needs longer to warm up than the probe allows. A crash-looping container has the same effect: 'new pods become ready or available' is the progress event that never happens, and with maxUnavailable enforced the rollout cannot advance past its first batch. - How to tell: kubectl get pods shows the newest ReplicaSet's pods Running but 0/1 READY (or CrashLoopBackOff), and kubectl describe pod shows Unhealthy probe events - **New pods are unschedulable and sit in Pending** _(common)_ - The new pod spec requests more CPU or memory than any node has free, or added a nodeSelector, affinity rule, or toleration requirement no node satisfies. The surge pods of a rolling update need headroom on top of the old pods that are still running, so a rollout can be unschedulable on a cluster where the steady state fits. - How to tell: New pods show STATUS Pending, and kubectl describe pod shows a FailedScheduling event from the scheduler - **The ReplicaSet cannot create pods at all — quota, limit ranges, or admission** _(common)_ - A ResourceQuota or LimitRange in the namespace, or an admission webhook, rejects pod creation outright. No pod objects appear, so there is nothing to describe at the pod level — the rejection is recorded on the Deployment as a ReplicaFailure condition and on the ReplicaSet's events. - How to tell: kubectl describe deployment shows ReplicaFailure True with reason FailedCreate, and the newest ReplicaSet has fewer CURRENT pods than DESIRED - **The new image cannot be pulled** _(common)_ - A typoed tag, a tag that was never pushed, or missing registry credentials. The pods schedule fine but wait in ImagePullBackOff forever, so no new pod ever becomes ready and the deadline fires. - How to tell: New pods show ImagePullBackOff or ErrImagePull in kubectl get pods, and the pod events quote the registry's error - **progressDeadlineSeconds is too short for a genuinely slow rollout** _(edge)_ - The deadline bounds the gap between progress events, not the whole rollout. A single step that legitimately takes longer than the deadline — a slow image pull on cold nodes, a long warm-up before readiness, a large minReadySeconds — trips the condition even though the rollout would have completed. The controller keeps retrying, so these rollouts often finish anyway with the failure condition already recorded. - How to tell: The pods do become ready, just later than the deadline — kubectl get deploy a few minutes later shows availability catching up with no spec change ## Solution 1. Confirm it is a progress failure and not just a slow rollout still in flight. A Deployment past its deadline makes rollout status exit non-zero with the deadline error; a healthy rollout ends in 'successfully rolled out' and exit code 0. ```bash kubectl rollout status deployment/ -n ; echo $? ``` 2. Read the Deployment's Conditions block. Progressing False with reason ProgressDeadlineExceeded confirms the diagnosis; a ReplicaFailure True condition alongside it means pod creation itself is being rejected and its message quotes the rejection — quota errors appear here verbatim. ```bash kubectl describe deployment -n ``` Note: kubectl get deployment -o yaml shows the same conditions with their full message fields, which describe sometimes truncates. 3. Drop down to the newest ReplicaSet and its pods — that is where the real blocker lives. The newest ReplicaSet is the one whose DESIRED is above zero but READY lags; its pods' status and events name the cause. ```bash kubectl get rs -n -l app=