Argo CD showed the Application as Progressing even though several pods were already Running. The important distinction is that Running is a pod phase, not proof that every managed resource has reached the health state Argo CD expects.
Find the resource holding the application in Progressing
Start with the detailed application tree:
argocd app get my-app --output tree=detailedThen inspect the resource that is still Progressing:
kubectl get deployment my-app -n production -o yaml
kubectl describe deployment my-app -n production
kubectl get pods -n production -l app=my-appFor Deployments, Argo CD checks rollout information such as observed generation and updated replicas. A pod can be running while the Deployment is still waiting for all desired replicas, readiness, or the latest generation to complete.
Useful fields to compare are:
kubectl get deployment my-app -n production \
-o jsonpath='generation={.metadata.generation}{"\n"}observed={.status.observedGeneration}{"\n"}desired={.spec.replicas}{"\n"}updated={.status.updatedReplicas}{"\n"}available={.status.availableReplicas}{"\n"}'If observedGeneration lags behind generation, or updated/available replicas do not match the desired count, fix the controller or rollout problem rather than forcing Argo CD to report Healthy.
Check custom resources separately
For a CRD, inspect the resource's status and conditions:
kubectl get <kind> <name> -n production -o yamlArgo CD can use a custom Lua health check when a controller has domain-specific health semantics. The health script belongs in the argocd-cm ConfigMap and should return Healthy, Progressing, Degraded, or another supported health status based on fields the controller actually writes.
Do not add a custom check that always returns Healthy; that hides real rollout failures. Test the check against healthy, progressing, and failed resource examples before deploying it.
What does not fix health evaluation
ignoreDifferences controls diff and synchronization behavior. It is not a general health override, and ignoring /status on a Deployment does not make a genuinely progressing rollout healthy.
A hard refresh is useful when cached application or manifest data is stale:
argocd app get my-app --hard-refreshArgo CD documents this as refreshing application data and the target manifest cache. If the same child resource remains Progressing after refresh, treat the resource's health or rollout as the root cause.
Verification
After correcting the workload or health customization:
argocd app get my-app --refresh
argocd app wait my-app --health --timeout 300The application should become Healthy without an ignoreDifferences rule that masks status. Also confirm the live workload:
kubectl rollout status deployment/my-app -n production --timeout=5mFor sync-state problems rather than health problems, use the Argo CD OutOfSync troubleshooting guide. If image automation is involved, see Argo CD Image Updater not picking up a tag.