How to fix ReplicaSet has timed out progressing in Kubernetes

KubernetesINTERMEDIATEHIGHUpdated Dec 5, 2025· 187 views

This error occurs when a Kubernetes Deployment fails to reach its desired state within progressDeadlineSeconds (default 10 minutes). Pods may be stuck due to image pull failures, scheduling issues, or resource constraints.

Quick fix

Fixes ReplicaSet has timed out progressing

kubectl describe deployment <deployment-name> -n <namespace>
  1. Check Deployment Status and Conditions
  2. Inspect Pod Events for Root Cause
  3. Verify Image Availability and Credentials
  4. Check Resource Availability and Quotas
kubernetes — error
kubectl describe deployment <deployment-name> -n <namespace>
ReplicaSet has timed out progressing

What this error means

In Kubernetes, a Deployment or ReplicaSet must progress toward its desired state within a specified deadline. The progressDeadlineSeconds field (default 600 seconds or 10 minutes) defines how long the controller will wait before marking the rollout as failed with a ProgressDeadlineExceeded condition. When this error occurs, it means that the ReplicaSet controller has been unable to create or schedule the required replicas within the timeout window. This is a symptom of an underlying issue—such as failed image pulls, insufficient resources, scheduling constraints, or API server communication problems—that prevents pods from reaching the Ready state. Kubernetes does not automatically take corrective action when this deadline is exceeded. It simply reports the condition and continues attempting the rollout. Higher-level orchestrators (like Argo Rollouts) can use this signal to trigger automated rollbacks, but the base Deployment will keep retrying indefinitely until the root cause is resolved.

Typical symptoms

  • Deployment status shows condition "Progressing: False" with reason "ProgressDeadlineExceeded"
  • Running kubectl rollout status command hangs or times out without the deployment completing
  • Pods remain in Pending, ImagePullBackOff, CrashLoopBackOff, or CreateContainerConfigError states
  • New ReplicaSet shows 0 ready replicas despite being created and having replica count defined
  • kubectl describe deployment shows no progress in desired vs. ready/updated replicas for extended period
  • Events display recurring FailedScheduling, FailedCreatePod, or image pull error messages

Common causes

  1. Container image is unavailable, inaccessible, or incorrect registry credentials—pods get stuck in ImagePullBackOff state
  2. Insufficient cluster resources (CPU, memory, disk) or node capacity exceeded—scheduler cannot place pods
  3. Readiness or liveness probes failing repeatedly—pods start but never reach Ready state
  4. Networking or API server communication failures—deployment controller cannot reach the API server
  5. Resource quotas or namespace limits exceeded—requests forbidden due to quota violations
  6. Pod scheduling failures due to node affinity, taints/tolerations, or pod affinity constraints
  7. progressDeadlineSeconds set too short for the application startup time

How to fix "ReplicaSet has timed out progressing"

1Check Deployment Status and Conditions

Get a detailed view of your deployment to see the exact condition and status:

bash
kubectl describe deployment <deployment-name> -n <namespace>

Look for the Conditions section which will show:
- Type: Progressing, Status: False, Reason: ProgressDeadlineExceeded
- The Message field often hints at the root cause

Also check the ReplicaSet status:

bash
kubectl get replicaset -n <namespace>
kubectl describe replicaset <replicaset-name> -n <namespace>
2Inspect Pod Events for Root Cause

Examine the pods created by the ReplicaSet to identify why they're not progressing:

bash
kubectl get pods -n <namespace> -l app=<app-label>
kubectl describe pod <pod-name> -n <namespace>

In the Events section, look for:
- ImagePullBackOff: Image cannot be pulled
- FailedScheduling: Pod cannot be scheduled
- CreateContainerConfigError: Missing secrets or configmaps
- CrashLoopBackOff: Container starts but immediately exits

Check pod logs:

bash
kubectl logs <pod-name> -n <namespace> --previous
kubectl logs <pod-name> -n <namespace>
3Verify Image Availability and Credentials

If you see ImagePullBackOff errors, validate that the container image exists and is accessible:

bash
# Check the image reference in your deployment
kubectl get deployment <deployment-name> -n <namespace> -o jsonpath='{.spec.template.spec.containers[*].image}'

# Verify imagePullSecrets are configured
kubectl get deployment <deployment-name> -n <namespace> -o jsonpath='{.spec.template.spec.imagePullSecrets}'

If the secret is missing, create it:

bash
kubectl create secret docker-registry <pull-secret-name> \
  --docker-server=<registry-url> \
  --docker-username=<username> \
  --docker-password=<password> \
  -n <namespace>
4Check Resource Availability and Quotas

Verify that your cluster has sufficient resources and that no quotas are blocking pod creation:

bash
# Check node resources
kubectl top nodes
kubectl describe nodes | grep -A 5 'Allocated resources'

# Check resource quotas in your namespace
kubectl describe resourcequota -n <namespace>

If resources are constrained, either increase the quota or reduce pod resource requests:

bash
kubectl set resources deployment <deployment-name> \
  --requests=cpu=100m,memory=128Mi \
  -n <namespace>
5Verify Readiness Probes and Pod Startup Time

If pods are created but not becoming Ready, the issue is often readiness probes failing:

bash
# Check readiness probe configuration
kubectl get deployment <deployment-name> -n <namespace> -o jsonpath='{.spec.template.spec.containers[*].readinessProbe}' | jq .

Adjust the probe settings for slow-starting applications:

yaml
spec:
  template:
    spec:
      containers:
      - name: app
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 30  # Give app time to start
          timeoutSeconds: 5
          periodSeconds: 10
          failureThreshold: 3
6Increase progressDeadlineSeconds or Rollback

If the root cause is just slow startup, extend the progress deadline:

bash
# Increase deadline to 20 minutes
kubectl patch deployment <deployment-name> -n <namespace> -p '{"spec":{"progressDeadlineSeconds":1200}}'

If you need to rollback:

bash
# Check rollout history
kubectl rollout history deployment <deployment-name> -n <namespace>

# Rollback to the previous revision
kubectl rollout undo deployment <deployment-name> -n <namespace>

# Verify the rollback
kubectl rollout status deployment <deployment-name> -n <namespace> --timeout=300s

Advanced notes

By default, Kubernetes uses the RollingUpdate strategy, which gradually replaces old pods. The progressDeadlineSeconds applies to the entire rollout window. When using Argo Rollouts, you get progressDeadlineAbort which stops and rolls back immediately upon exceeding the deadline, whereas native Kubernetes Deployments continue retrying.

The minReadySeconds field defines how long a pod must be Ready before it counts toward the desired state. Setting this too high combined with slow readiness probes can cause artificial timeout conditions. Ensure minReadySeconds < progressDeadlineSeconds.

For debugging, kubectl rollout status also has its own timeout (2 minutes default) separate from progressDeadlineSeconds. Use --timeout=1h with this command to avoid client-side timeout masking the actual issue.

Frequently asked questions

What does "ReplicaSet has timed out progressing" mean?
In Kubernetes, a Deployment or ReplicaSet must progress toward its desired state within a specified deadline. The progressDeadlineSeconds field (default 600 seconds or 10 minutes) defines how long the controller will wait before marking the rollout as failed with a ProgressDeadlineExceeded condition. When this error occurs, it means that the ReplicaSet controller has been unable to create or schedule the required replicas within the timeout window.
How do I fix "ReplicaSet has timed out progressing"?
This error occurs when a Kubernetes Deployment fails to reach its desired state within progressDeadlineSeconds (default 10 minutes). Pods may be stuck due to image pull failures, scheduling issues, or resource constraints.
What causes "ReplicaSet has timed out progressing"?
Container image is unavailable, inaccessible, or incorrect registry credentials—pods get stuck in ImagePullBackOff state Insufficient cluster resources (CPU, memory, disk) or node capacity exceeded—scheduler cannot place pods Readiness or liveness probes failing repeatedly—pods start but never reach Ready state
Is the "ReplicaSet has timed out progressing" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading