Kubernetes detects a stalled rollout with the progressDeadlineSeconds field on a Deployment. When the deadline passes without progress, the controller records a Progressing condition with status False. It reports the problem. It does not undo the release, so you need your own rollback trigger.
What the controller does by default
A rolling update replaces pods gradually. The Kubernetes documentation says the controller stops a bad rollout automatically in one sense: it stops scaling up the new ReplicaSet, and this depends on the rollingUpdate parameters, especially maxUnavailable, which defaults to 25 percent. The old pods keep serving, so users are mostly protected.
What it does not do is decide the release is wrong and go back. The documentation's own walkthrough shows a human noticing the stuck rollout and running a rollback.
What counts as stuck
The documentation lists common causes of a rollout that cannot progress: insufficient quota, readiness probe failures, image pull errors, insufficient permissions, limit ranges and application runtime misconfiguration. Several of these are exactly what a deploy-time control produces on purpose.
| Cause | Possible security meaning |
|---|---|
| Image pull errors | Image not in the approved registry, or signature check failed upstream |
| Insufficient permissions | A tightened RBAC or service account change |
| Limit ranges and quota | A resource guardrail doing its job |
| Admission rejection of pods | Policy denied the new pod, visible in ReplicaSet events |
| Readiness probe failures | Often a bug, occasionally a blocked dependency |
A rollout that stalls right after you add a policy is usually not a platform fault. Read the events before you assume so.
Set a deadline you can live with
The documentation shows setting the field with a patch, for example 600 seconds for ten minutes. Pick a value that matches how long a healthy rollout takes for that service, plus margin. Too short and slow starts look like failures. Too long and a blocked security fix waits unnoticed.
kubectl patch deployment/web -p '{"spec":{"progressDeadlineSeconds":600}}'
kubectl rollout status deployment/web
kubectl rollout status waits and exits with a failing code when the deadline is exceeded, so a CI or deploy job can use it as a check.
Turn the signal into an action
- Make your pipeline wait on rollout status, and fail the job on a stall.
- On failure, collect ReplicaSet events and pod events as evidence before anything is cleaned up.
- Decide in advance whether the job rolls back automatically or pages a person. For security fixes, many teams prefer a person, because an automatic undo may reinstall the vulnerable version.
- Record the outcome in the deployment record.
Progressive delivery tools can automate analysis and abort, but the principle is the same: define the failure condition before the release, not during it.
Where Safeguard fits
Safeguard's continuous monitoring watches your projects for new findings after release, so a stalled fix and a newly disclosed issue show up in the same view. Its policies and gates define what is allowed to ship in the first place.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a change in findings appears after something is already deployed.
Quick check
Does Kubernetes roll back a failed rollout automatically?
No. It stops scaling up the new ReplicaSet and reports the stall. Rolling back is a separate action you take or automate.
Where do I look first when a rollout stalls after a policy change?
Check ReplicaSet and pod events. Admission denials are reported there.
Sources
Last reviewed: 19 October 2026.
