Argo CD Application health status lag during deployment failures

Answer the exact question first

Argo CD’s Application controller polls the Kubernetes API to reconcile desired and live state. The latency between a failure event (e.g., CrashLoopBackOff) and the UI showing Degraded is controlled by a handful of timeout settings in the argocd-cm ConfigMap.

Configuration knobs that directly influence sync lag

• timeout.reconciliation – The maximum time a resource is considered for a reconciliation loop. Default: 3m (Argo CD 2.7+). Setting it to 30s or 15s will make the controller re‑evaluate a resource more frequently.
• timeout.resource – The timeout applied to individual resource syncs. Default: 3m. Lowering this reduces how long a resource can stay in a pending state before the controller retries.
• resource.customizations.health – While not a polling interval, you can provide a custom health.lua script that returns Degraded immediately when a pod status matches a failure pattern, bypassing the default health‑check delay.
• resource.customizations.refresh – Setting refresh: sync forces a refresh on every sync operation instead of the default OnChange, which can tighten the loop when deployments fail.

How to apply the changes

# Inspect current settings
kubectl -n argocd get cm argocd-cm -o yaml | grep -E 'timeout.reconciliation|timeout.resource'

# Patch the ConfigMap (example: set reconciliation to 30s)
kubectl -n argocd patch cm argocd-cm --type merge -p '{"data":{"timeout.reconciliation":"30s"}}'

# (Optional) Add a custom health script
kubectl -n argocd patch cm argocd-cm --type merge -p '{"data":{"resource.customizations.health":"{\"Deployment\":{\"health.lua\":\"...\"}}"}}'

Impact on performance in high‑volume environments

Every reduction in these intervals increases the number of API calls the Application controller makes. In clusters with thousands of resources:

• CPU and memory usage of the controller can rise sharply, especially if timeout.reconciliation is set below 30 s.
• API server throttling (429 responses) may start occurring if the request rate exceeds the cluster’s limits.
• Long‑running syncs can back‑pressure other controllers, potentially affecting cluster responsiveness.

Best practice is to:

• Monitor argocd-application-controller metrics (CPU, memory, API request count) after each change.
• Gradually tighten the timeout, starting at 30 s and observing the effect.
• Consider adding a health.lua script for the most critical workloads so that the UI reflects failures almost instantly without globally lowering polling intervals.

Missing diagnostic detail that could refine the recommendation

How many resources does your application manage, and what is the average API server request limit on your cluster? Knowing this will help decide whether a 15 s timeout is safe or if a 30 s setting is preferable.