ProgressDeadlineExceeded: The Deployment made no progress within its deadline and gave up reporting success

This condition means a rollout stopped making progress for progressDeadlineSeconds — 600 by default. It is a report, not an action: nothing is rolled back, and the Deployment keeps trying.

Applies to: All Kubernetes versions

What it means

A Deployment tracks whether its rollout is advancing. If no new pod becomes available and no other progress is made within progressDeadlineSeconds, the Progressing condition is set to false with reason ProgressDeadlineExceeded. Two things about this are commonly misunderstood. First, it changes nothing operationally — the ReplicaSet keeps trying to create pods, and if the problem resolves the rollout completes normally. Second, it does not roll back. Automatic rollback is not a Deployment feature; that behaviour comes from CI tooling or a progressive delivery controller layered on top. So the condition's value is as a signal that something upstream is wrong, and the actual cause is always in the new pods.

Most common causes

• The new pods are failing to start — a bad image, a crash loop, a missing ConfigMap.
• The new pods start but never become Ready, because a readiness probe never passes.
• The new pods cannot be scheduled at all, so no progress is possible.
• A quota preventing the surge pods a rolling update needs.
• A volume that will not attach for the new pods.
• A deadline that is genuinely too short for a workload with a long startup.

How to diagnose it

1. Read the Deployment's conditions: kubectl describe deployment DEPLOY. The reason is there but not the cause.
2. Go to the new ReplicaSet and its pods, which is where the real error is: kubectl get rs -n NAMESPACE, newest first, then kubectl describe pod on one of its pods.
3. Check rollout status directly: kubectl rollout status deployment/DEPLOY.
4. If no pods exist at all for the new ReplicaSet, read the ReplicaSet's events — quota and admission rejections land there, not on the pods.
5. Compare the workload's real startup time against progressDeadlineSeconds.

How to fix it

1. Fix whatever is wrong with the new pods. The condition clears on its own once they become available.
2. Roll back deliberately if the new version is bad: kubectl rollout undo deployment/DEPLOY.
3. Raise progressDeadlineSeconds only if the workload legitimately takes longer than the default to become available.
4. Set maxUnavailable: 0 so a failing rollout does not take down healthy old pods while it stalls.
5. Free quota, or set maxSurge: 0, if the surge pods cannot be created.

Notes

Because nothing is rolled back automatically, a Deployment can sit in this state indefinitely with old pods still serving traffic. That is usually the desired outcome — but it means the condition needs monitoring, since the workload appears healthy from the outside while the new version has never shipped.

Related

• FailedCreate — A controller could not create its pods
• Readiness probe failed — The pod was removed from service endpoints

Sources

• Kubernetes documentation — Deployments: failed deployment
• Kubernetes documentation — Deployments
• Kubernetes documentation — ReplicaSet