Kubernetes Deployment Rollout Stuck: How to Fix 'Waiting for Rollout to Finish' (2026)

Fix for Kubernetes deployments stuck in rollout — covering insufficient cluster resources, failing readiness probes, PodDisruptionBudgets blocking drain, and max unavailable settings causing stalls.

You run kubectl rollout status deployment/my-app expecting a quick confirmation, and instead you see:

Waiting for deployment "my-app" rollout to finish: 1 out of 3 new replicas have been updated...

And it just stays there. The progress bar of infrastructure anxiety.

A stuck rollout means Kubernetes is trying to update pods but cannot complete the process. Here is how to diagnose exactly what is blocking it.

Step 1: Check What the Deployment is Actually Doing

bash

kubectl get deployment my-app -n production

Look at the READY column:

NAME     READY   UP-TO-DATE   AVAILABLE   AGE
my-app   2/3     1            2           5m

This tells you: 3 replicas are desired, only 2 are ready, 1 pod has been updated to the new version but the overall rollout is stuck.

Now get events and pod status:

bash

kubectl describe deployment my-app -n production
kubectl get pods -n production -l app=my-app

Root Cause 1: New Pods Not Passing Readiness Probe

The most common cause. The new version of your app is starting but failing its readiness probe, so Kubernetes keeps the old pods around (rightly) and will not continue the rollout.

bash

# Check pod status
kubectl get pods -n production -l app=my-app
# new-pod-7d9f-abc   0/1   Running   0   3m
 
# Describe the new pod
kubectl describe pod new-pod-7d9f-abc -n production

Look in Events for:

Readiness probe failed: Get http://10.0.0.5:8080/health: connection refused

Or:

Readiness probe failed: HTTP probe failed with statuscode: 500

Fix: Your new version has a bug that is causing the health endpoint to fail. Options:

Fix the bug, push a new image, and update the deployment
Roll back: kubectl rollout undo deployment/my-app -n production

bash

# Quick rollback
kubectl rollout undo deployment/my-app -n production
 
# Verify rollback completed
kubectl rollout status deployment/my-app -n production

Root Cause 2: Insufficient Cluster Resources

The new pods cannot be scheduled because the cluster does not have enough CPU or memory to place them.

bash

# Check pod status — look for Pending pods
kubectl get pods -n production
# new-pod-7d9f-xyz   0/1   Pending   0   5m
 
# Describe the Pending pod
kubectl describe pod new-pod-7d9f-xyz -n production

Events will show:

Warning  FailedScheduling  0/3 nodes are available: 
  1 Insufficient cpu, 2 node(s) had taint that pod didn't tolerate.

Why this happens during a rollout: By default, a Deployment rolling update creates new pods before removing old ones (depending on maxSurge). During the overlap, you temporarily need resources for both old and new pods.

Fix options:

bash

# Option 1: Scale up the cluster (add nodes)
# Option 2: Reduce resource requests in the deployment
# Option 3: Adjust rollout strategy to use less surge:
kubectl patch deployment my-app -n production -p '{
  "spec": {
    "strategy": {
      "type": "RollingUpdate",
      "rollingUpdate": {
        "maxSurge": 0,
        "maxUnavailable": 1
      }
    }
  }
}'

Setting maxSurge: 0 means Kubernetes removes an old pod before creating a new one, reducing peak resource requirements.

Root Cause 3: PodDisruptionBudget Blocking Pod Removal

A PodDisruptionBudget (PDB) can block the rollout if removing old pods would violate the minimum availability requirement.

bash

# Check if PDBs exist for this deployment
kubectl get pdb -n production
 
# Example output:
# NAME     MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
# my-app   2               N/A               0                     30d

If ALLOWED DISRUPTIONS: 0, Kubernetes cannot remove any old pods because the PDB requires at least 2 pods to be available at all times, but only 2 are currently running (not 3 as desired).

Fix: Either wait for Kubernetes to bring up the new pod first (if resources allow), or temporarily adjust the PDB:

bash

# Temporarily lower the minimum available
kubectl patch pdb my-app -n production -p '{"spec":{"minAvailable":1}}'
 
# After rollout completes, restore
kubectl patch pdb my-app -n production -p '{"spec":{"minAvailable":2}}'

Root Cause 4: Wrong Image Tag or Image Pull Error

The new pod cannot start because the image does not exist or the pull is failing.

bash

kubectl get pods -n production -l app=my-app
# new-pod   0/1   ImagePullBackOff   0   3m
 
kubectl describe pod new-pod -n production
# Events:
# Failed to pull image "myapp:v2.4.1": rpc error: code = NotFound

Fix: Update the deployment to use a valid image tag:

bash

kubectl set image deployment/my-app \
  container-name=myapp:v2.4.0 \
  -n production

Root Cause 5: Slow Startup Time + Short Deadlines

If your app takes longer to start than the rollout's progressDeadlineSeconds:

yaml

spec:
  progressDeadlineSeconds: 300  # Default is 600 seconds
  template:
    spec:
      containers:
      - name: app
        readinessProbe:
          initialDelaySeconds: 10
          periodSeconds: 5
          failureThreshold: 3
          # Total time: 10 + (3 * 5) = 25 seconds max before pod is NotReady

If your app needs 60 seconds to start but the readiness probe gives up after 25 seconds, the pod will never become Ready.

Fix: Increase initialDelaySeconds or failureThreshold:

yaml

readinessProbe:
  initialDelaySeconds: 60  # Wait 60s before first check
  periodSeconds: 10
  failureThreshold: 6      # Try for 60 more seconds

Rollout Status Commands to Know

bash

# Check rollout status (blocks until complete or fails)
kubectl rollout status deployment/my-app -n production --timeout=5m
 
# See rollout history
kubectl rollout history deployment/my-app -n production
 
# Pause a rollout
kubectl rollout pause deployment/my-app -n production
 
# Resume a paused rollout
kubectl rollout resume deployment/my-app -n production
 
# Roll back to previous version
kubectl rollout undo deployment/my-app -n production
 
# Roll back to specific revision
kubectl rollout undo deployment/my-app -n production --to-revision=3

Diagnosis Flowchart

Rollout stuck
    ↓
kubectl get pods → check new pod status
    ↓
Pending → check resources: kubectl describe pod → FailedScheduling → add nodes or reduce maxSurge
    ↓
Running 0/1 → readiness probe failing → check kubectl logs new-pod → fix app bug or roll back
    ↓
ImagePullBackOff → wrong image tag → fix image reference
    ↓
Everything looks Running/Ready but old pods not removed → check PDB allowed disruptions
    ↓
Still stuck → check progressDeadlineSeconds vs actual startup time

More Kubernetes troubleshooting? Read our Kubernetes deployment imagePullBackOff fix and Kubernetes PDB blocking node drain fix.

Kubernetes Deployment Rollout Stuck: How to Fix 'Waiting for Rollout to Finish' (2026)

Step 1: Check What the Deployment is Actually Doing

Root Cause 1: New Pods Not Passing Readiness Probe

Root Cause 2: Insufficient Cluster Resources

Root Cause 3: PodDisruptionBudget Blocking Pod Removal

Root Cause 4: Wrong Image Tag or Image Pull Error

Root Cause 5: Slow Startup Time + Short Deadlines

Rollout Status Commands to Know

Diagnosis Flowchart

Stay ahead of the curve

Related Articles

ArgoCD App of Apps Not Syncing — Every Fix (2026)

ArgoCD Image Updater Not Syncing — Fix Guide

ArgoCD Resource Hook Failed: How to Debug and Fix It

Comments