Assign an owner for failed Kubernetes Deployment rollouts

A progress deadline reports a stalled rollout; it does not perform the rollback itself.

Source facts

Kubernetes can mark a Deployment’s Progressing condition false with reason ProgressDeadlineExceeded when rollout progress exceeds its deadline. The Deployment controller takes no corrective action beyond reporting that condition. A higher-level orchestrator may use it to trigger a response. Paused rollouts are not checked against the progress deadline while they remain paused.

Source: Kubernetes documentation — Deployments.

Applicability

Review Deployment progress reporting, response ownership and the handling of paused rollouts.

DSE recommendation

DSE recommends defining who receives the stalled-rollout alert and who can choose retry, repair, or rollback. Keep the last known usable configuration and relevant application-data compatibility constraints with the release record. Examine image pulls, scheduling, readiness, and application errors before blindly repeating a rollout. An automated responder should have a clear trigger and an auditable action rather than relying on the word deadline to imply recovery. Document how paused changes are tracked so a deliberate pause does not become an unnoticed unfinished release.

Verification

In a test Deployment, introduce a safely failing readiness condition and observe the reported deadline status. Confirm that the chosen delivery process alerts or acts as documented. Restore the approved configuration and verify readiness before treating the exercise as complete. Have the release operator show the exact alert and the documented decision owner. If an external delivery system performs rollback, preserve its own action record separately from the Deployment condition that triggered it.

Official reference

Kubernetes documentation — Deployments. Reviewed October 20, 2026.