Sync Strategies, Health & Self-Healing
Automate deployments, correct drift, and control the order things roll out.
Manually clicking “Sync” is fine to learn, but the real power of Argo CD is automation: deploy on every commit, correct drift automatically, and control rollout order. This lesson covers sync policies, self-healing, pruning, and health checks.
🎯 Learning Objectives
- Enable automated sync
- Understand self-heal and prune
- Use sync waves to order resources
- Understand how Argo CD assesses health
Manual vs. Automated Sync
By default, sync is manual — Argo CD shows OutOfSync and waits for you. Turn on automated sync and it applies changes as soon as Git changes:
spec:
syncPolicy:
automated:
prune: true # delete resources removed from Git
selfHeal: true # revert manual changes made in the cluster
syncOptions:
- CreateNamespace=trueTwo flags do the heavy lifting:
| Option | What it does |
|---|---|
prune |
When you delete a manifest from Git, Argo CD deletes it from the cluster too |
selfHeal |
When someone changes the live cluster by hand, Argo CD reverts it back to Git |
⚠ Prune deletes things — enable it deliberately
With prune: true, removing a file from Git removes the resource from the cluster. That’s exactly what you want for true GitOps, but be sure your Git repo really is the complete source of truth before enabling it.
Self-Healing in Action
Self-heal is what makes the cluster tamper-resistant. Suppose someone scales a deployment by hand:
Git still says 3 replicas. Argo CD detects the drift and, with selfHeal: true, reverts it:
The lesson: change the cluster by changing Git, never by hand.
Sync Waves — Controlling Order
Some resources must exist before others (a database before the app that uses it, a namespace before its contents). Sync waves let you order the rollout using an annotation:
metadata:
annotations:
argocd.argoproj.io/sync-wave: "0" # runs first (lower = earlier)Resources in wave 0 sync and become healthy before wave 1 starts, and so on. Negative numbers run even earlier. This is how you sequence dependencies cleanly.
💡 Hooks for one-off steps
For things like database migrations, use resource hooks (PreSync, Sync, PostSync) — jobs that run at a specific point in the sync, e.g. run a migration PreSync before the new app version rolls out.
How Argo CD Assesses Health
Sync status answers “does the cluster match Git?” — health answers “are the resources actually working?” Argo CD has built-in health checks per resource kind:
| Resource | Healthy when… |
|---|---|
| Deployment | Desired replicas are available and updated |
| Service | Allocated correctly (LoadBalancer has an address) |
| Ingress | Load balancer is provisioned |
| Pod | Running / succeeded |
An app can be Synced but Degraded — e.g. the manifests applied fine, but the pods are crash-looping. Watching both statuses together tells the full story.
🧪 Hands-on Lab
Design a Safe Auto-Sync Policy
You want an app that (a) deploys automatically on commit, (b) reverts manual cluster edits, and (c) removes resources deleted from Git — but you also need the database Job to run before the app deployment. Sketch the syncPolicy and the ordering annotation.
🧠 Knowledge Check
What does the selfHeal option do?
An app shows Sync Status: Synced but Health: Degraded. What does that mean?
💼 Interview Preparation
What's the difference between sync status and health status in Argo CD?
Summary
You now know how to automate sync, self-heal drift, prune deleted resources, order rollouts with sync waves, and read health status. Next, we scale this up to managing many applications the GitOps way with the App of Apps pattern and production best practices.