How to fix ArgoCD degraded in Kubernetes

KubernetesINTERMEDIATEHIGHUpdated Dec 6, 2025· 782 views

An ArgoCD application shows "Degraded" status when one or more of its managed resources are failing their health checks. This is distinct from sync failures and indicates the deployed application is not running healthily. Fix by identifying which resources are unhealthy and addressing the underlying issues (failed deployments, unavailable pods, misconfigured services).

Quick fix

Fixes ArgoCD degraded

argocd app get <app-name>
  1. Check application health in ArgoCD
  2. Inspect individual resource status
  3. Review pod and container logs
  4. Check pod events and readiness/liveness probes
kubernetes — error
argocd app get <app-name>
ArgoCD degraded

What this error means

A "Degraded" status in ArgoCD means that one or more of the resources managed by your Application (Deployments, StatefulSets, Services, Ingresses, etc.) is failing its health check. Unlike "Sync failed" (which indicates problems during deployment), "Degraded" is about post-deployment application health. The status is continuously updated and reflects the worst health of all child resources. ArgoCD's health hierarchy is: Healthy > Suspended > Progressing > Missing > Degraded > Unknown. If any resource is degraded, the entire application is marked degraded.

Typical symptoms

  • Application status shows "Degraded" in ArgoCD dashboard
  • Health status is red while sync status is green (synced)
  • One or more resources show unhealthy status in application details
  • Pods are not running, crashing, or pending
  • Deployments have fewer replicas ready than desired
  • Ingress endpoints are unreachable or missing
  • StatefulSet or DaemonSet has unavailable replicas

Common causes

  1. Pod crash or CrashLoopBackOff (application startup failure)
  2. Insufficient resources (memory, CPU, disk) causing pod eviction
  3. Deployment replica mismatch (HPA scaling up but replicas not ready)
  4. Broken container image or missing image in registry
  5. Liveness or readiness probe failures
  6. Missing dependencies (ConfigMaps, Secrets, PersistentVolumes)
  7. Service endpoints not available or DNS resolution failing
  8. Resource temporarily in Progressing state during rollout

How to fix "ArgoCD degraded"

1Check application health in ArgoCD

View detailed health status in the ArgoCD UI or CLI:

bash
argocd app get <app-name>

Or in the web UI, navigate to Applications and click the degraded app. Look for the "Resources" tab showing each resource's health status. Identify which specific resource(s) are degraded (shown in red).

2Inspect individual resource status

Check the degraded resource directly:

bash
kubectl describe pod <pod-name> -n <namespace>
kubectl describe deployment <deployment-name> -n <namespace>
kubectl get <resource-type> -n <namespace> -o wide

Look for:
- "Ready" column (replicas ready vs desired)
- "Status" field showing Pending, CrashLoopBackOff, or Error
- Events section with error messages or warnings

3Review pod and container logs

Check logs from the failing pod:

bash
kubectl logs <pod-name> -n <namespace>
kubectl logs <pod-name> -n <namespace> --previous  # For crashed containers
kubectl logs <pod-name> -c <container-name> -n <namespace>  # Specific container

Look for:
- Stack traces or error messages
- Connection failures to dependencies
- Configuration errors
- Probe failures

4Check pod events and readiness/liveness probes

Get detailed events and probe configuration:

bash
kubectl describe pod <pod-name> -n <namespace>
# Look at "Events" section and "Readiness" / "Liveness" rows

# View probe configuration
kubectl get pod <pod-name> -o yaml | grep -A 10 "readinessProbe\|livenessProbe"

If probes are failing, they may be misconfigured (wrong port, path, threshold) or the app needs more time to initialize. Consider adding a startupProbe.

5Verify resource availability and dependencies

Check for missing ConfigMaps, Secrets, PersistentVolumes:

bash
kubectl describe pod <pod-name> -n <namespace> | grep -A 20 "Mounts\|Volumes"
kubectl get configmap,secret -n <namespace> -o wide
kubectl get pv,pvc -n <namespace>

If volumes are not mounting or configs are missing, create them:

bash
kubectl create configmap app-config --from-file=config.yaml -n <namespace>
6Check for HPA-induced transient degradation

HorizontalPodAutoscaler can cause temporary degradation:

bash
kubectl get hpa -n <namespace>
kubectl describe hpa <hpa-name> -n <namespace>

When HPA scales up, new replicas take time to become ready. ArgoCD may mark the app degraded until all new replicas pass health checks. This usually resolves automatically. To reduce false positives, add a startup probe or adjust HPA scaling policies.

7Sync and verify in ArgoCD

Once you've fixed the underlying resource issue (restarted pod, increased resource limits, fixed config), re-sync the application:

bash
argocd app sync <app-name>
argocd app wait <app-name>  # Wait for healthy status

Or use the web UI: click the app > "SYNC" button. Monitor the Resources tab until all turn green.

Advanced notes

Degraded status is always tied to a specific resource failing its health check—it's never ArgoCD itself that's degraded. Custom resources (CRDs) may need custom health checks defined in argocd-cm if they're stuck in Progressing. For controller-managed resources (e.g., Anthos Config Connector), expect transient degradation until the controller completes provisioning. Use kubectl top to check actual resource usage vs requests/limits. Consider setting up ArgoCD notifications/alerts (via Slack, email) to alert on degradation events. The difference between "Degraded" and "Sync Failed": Degraded = runtime issue (app not healthy), Sync Failed = deployment issue (kubectl apply failed).

Frequently asked questions

What does "ArgoCD degraded" mean?
) is failing its health check. Unlike "Sync failed" (which indicates problems during deployment), "Degraded" is about post-deployment application health. The status is continuously updated and reflects the worst health of all child resources.
How do I fix "ArgoCD degraded"?
An ArgoCD application shows "Degraded" status when one or more of its managed resources are failing their health checks. This is distinct from sync failures and indicates the deployed application is not running healthily. Fix by identifying which resources are unhealthy and addressing the underlying issues (failed deployments, unavailable pods, misconfigured services).
What causes "ArgoCD degraded"?
Pod crash or CrashLoopBackOff (application startup failure) Insufficient resources (memory, CPU, disk) causing pod eviction Deployment replica mismatch (HPA scaling up but replicas not ready)
Is the "ArgoCD degraded" 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