How does Argo CD's ignoreDifferences configuration interact with its automated self-healing (selfHeal) feature?
Short Answer
ignoreDifferences runs first, conceptually: it removes specific fields from Argo CD's diff calculation entirely, so a live value differing from Git in an ignored field is never even seen as drift in the first place — and since selfHeal only acts on detected drift, an ignored field is never a candidate for self-healing to revert, regardless of how much it diverges from the Git-declared value. The two features are complementary rather than competing: ignoreDifferences defines what counts as drift at all, and selfHeal decides what to do about whatever's left after that filtering.
Detailed Explanation
Argo CD's sync status is computed by diffing the live cluster state against what's declared in Git, field by field. ignoreDifferences configures specific fields (or entire paths, via JSON pointers or a Kubernetes-native managedFieldsManagers approach) to be excluded from that diff calculation — meaning Argo CD never even compares those specific fields between live and Git state, so no divergence there is ever registered as drift, regardless of how different the live value actually is.
selfHeal (part of the automated sync policy) acts on whatever is detected as drift — when live state diverges from Git in a field that Argo CD is actually comparing, selfHeal triggers an automatic sync to revert that divergence back to the Git-declared value, without waiting for a human to notice and manually sync. Since ignoreDifferences has already removed certain fields from the comparison entirely, those fields are structurally invisible to selfHeal — there's no drift for it to detect or revert in an ignored field, no matter what value it holds live.
This relationship is exactly why ignoreDifferences is the correct tool for fields legitimately mutated by something other than Argo CD (a mutating webhook injecting a sidecar container spec, a Horizontal Pod Autoscaler adjusting replica count, a cloud provider populating a Service's external IP) — without ignoreDifferences, selfHeal would fight that external mutator, repeatedly reverting its changes back to the Git-declared value the instant they're made, causing a genuinely disruptive reconciliation loop. With the field correctly ignored, selfHeal simply never engages with it, letting the external mutator's changes persist undisturbed while selfHeal still actively protects every field that is being compared.
Interview Follow-Up Questions
- How would you decide whether a diverging field should be handled with `ignoreDifferences` versus updating the Git source to match reality?
- What's the risk of over-using `ignoreDifferences` across many fields — what protection does that trade away?
- How would you audit an Argo CD Application's `ignoreDifferences` configuration to make sure it's not silently masking a real, unwanted drift?
Key Takeaways
ignoreDifferencesremoves specific fields from Argo CD's diff calculation entirely, beforeselfHealever gets involved.selfHealonly acts on fields that are actually being compared — an ignored field is structurally invisible to it, regardless of live drift.- This is exactly why
ignoreDifferencesis the correct tool for fields legitimately mutated by something other than Argo CD — without it,selfHealwould fight that external mutator continuously. - The two features are complementary:
ignoreDifferencesdefines the scope of what counts as drift;selfHealdecides the response to whatever's left in that scope.
References
Related Questions
- A mutating webhook injects configuration into your resources. When should that injected config actually be tracked in Git instead of ignored via ignoreDifferences?SuggestedAdvanced
- How would you handle an Argo CD migration Job that should run on every sync versus one that should only run when the migration itself actually changed?SuggestedAdvanced
- If an Argo CD PreSync hook Job fails, does Argo CD retry it automatically? How would you make that retry behavior explicit instead of relying on defaults?SuggestedIntermediate
Last updated August 21, 2026 · Last reviewed August 21, 2026