How GitOps Sync and Drift Detection Work

Originally published in February 2025. Last updated August 2026.

Argo CD is an open-source, GitOps-based continuous delivery tool built natively for Kubernetes. It continuously compares the target state of a Kubernetes cluster with the live state present in the Git repository, using Git repositories as the single source of truth, to identify drift and automate synchronization.

This guide covers that loop in detail: how drift is detected, what sync status and health status each report, how to tune the reconciliation interval, and what automated, selfHeal, and prune actually do. It is written for platform engineers and SREs already running Argo CD who need to decide how aggressively it should enforce Git, and for teams evaluating whether automated reconciliation is safe for their workloads. 

For a broader introduction to Argo CD, its architecture, and its deployment models, read the complete guide to Argo CD.

TL;DR

1. Argo CD is an open-source, pull-based GitOps tool that uses Git, Helm or OCI sources to define the desired state of Kubernetes applications.

2. The Application Controller compares live resources with the target state and marks applications as Synced or OutOfSync.

3. Argo CD tracks synchronization separately from health states such as Healthy, Progressing and Degraded.

4. A configured syncPolicy can enable automated sync, self-healing, and pruning when live resources drift from the desired state.

5. Drift is detected on a 120-second reconciliation interval by default. Git webhooks reduce that to near-immediate.

6. ignoreDifferences prevents Argo CD from repeatedly reverting changes made by other controllers that legitimately mutate live resources.

7. For teams that need to move changes progressively across environments, Argo CD pairs with Kargo, an environment promotion tool.

How Does Argo CD Detect Drift?

The Application Controller runs in-cluster and compares each application's live state against its target state on a continuous loop. When the two differ, the application is marked OutOfSync. What happens next depends entirely on the syncPolicy attached to it.

Drift has two sources, and Argo CD treats them the same way:

• A new revision changed the target state. A developer merges an updated manifest into a tracked branch, Argo CD detects the new revision, and the generated manifests no longer match what is running.

• Someone changed the live resource. A kubectl edit, a failed deploy, an admission controller, or another automation modified a resource out-of-band.

Both surface identically in the UI and both are governed by the same policy. Automated sync alone reconciles only the first of these, a changed target state. Reverting an out-of-band change requires selfHeal.               

The Application and Sync Policy

The syncPolicy block determines how Argo CD responds to detected drift or new revisions. The top-level control is the automated block, which enables unattended synchronization; prune and selfHeal are options within it that refine that behavior:

• Automated Sync (automated): Automatically synchronizes the application when a new revision changes the desired state, bringing live resources in line with the target manifests without manual intervention.

• Self-Healing (selfHeal): Extends automated sync to live-state drift. Without it, an out-of-band change to a live resource is surfaced as OutOfSync but left in place until a human or a Git change acts on it; with selfHeal: true, Argo CD reverts the resource back to the state defined in Git, preserving it as the authoritative source of truth.

• Automated Pruning (prune): Deletes cluster resources that are no longer defined in the desired application state. It is disabled by default as a safeguard against accidental removal.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: guestbook
  # Applications live in the Argo CD namespace by default. To manage
  # Applications from other namespaces, the "apps-in-any-namespace"
  # feature must be enabled and the namespace allow-listed.
  namespace: argocd
  finalizers:
    # Triggers cascading deletion: removing this Application also prunes
    # the resources it deployed. Omit it and deleting the Application
    # leaves the managed resources orphaned in the cluster.
    - resources-finalizer.argocd.argoproj.io
spec:
  # The Argo CD AppProject this Application belongs to. Projects scope
  # which repos, destinations, and resource kinds are permitted.
  # "default" is the built-in, unrestricted project.
  project: default
  source:
    # Where the desired state lives. Can be a Git repo, a Helm repo,
    # or an OCI registry (oci://...).
    repoURL: https://github.com/argoproj/argocd-example-apps.git
    # The revision to track. For Git: a branch, tag, or commit SHA
    # (e.g. HEAD, main, v1.2.3). For Helm/OCI: a chart version or
    # semver constraint (e.g. 1.2.* or >=1.0.0 <2.0.0).
    targetRevision: HEAD
    # Directory within the repo containing the manifests. Argo CD
    # auto-detects the tool (plain YAML, Kustomize, Helm, Jsonnet).
    path: guestbook
    # Tool-specific config is optional. Example for Helm:
    # helm:
    #   valueFiles:
    #     - values-prod.yaml
    #   parameters:
    #     - name: image.tag
    #       value: v2.0.0
  destination:
    # The target cluster. Use the in-cluster API endpoint for the
    # cluster Argo CD runs in, or a registered cluster's URL.
    server: https://kubernetes.default.svc
    # Alternatively, reference a cluster by its registered name
    # (mutually exclusive with `server`):
    # name: prod-us-east
    # The namespace resources are applied to when a manifest doesn't
    # specify its own. Cluster-scoped resources ignore this.
    namespace: guestbook
  syncPolicy:
    # Omit this whole block for manual syncs (drift is still detected
    # and surfaced as OutOfSync, just not reconciled automatically).
    automated:
      # Delete resources that exist in the cluster but no longer in
      # the target state. Defaults to false as a safety guard.
      prune: true
      # Automatically revert out-of-band changes to live resources
      # back to the target state.
      selfHeal: true
      # Allow a sync that would leave zero resources (e.g. everything
      # was pruned). Defaults to false to prevent accidental wipes.
      allowEmpty: false
    syncOptions:
      # Create the destination namespace if it doesn't exist.
      - CreateNamespace=true
      # Use server-side apply instead of client-side (helps with
      # large resources and field-manager conflicts).

Omitting the automated block entirely leaves the application on manual sync. Drift is still detected and surfaced, though an operator must approve the reconciliation. That is the right default for high-risk production workloads and for teams introducing GitOps gradually.

How Does Argo CD Monitor and Sync Applications?

Argo CD manages applications through a continuous reconciliation loop. Rather than checking cluster status only when a pipeline runs, the Application Controller continuously evaluates two independent statuses for every managed application:

• Sync Status (Synced vs. OutOfSync): Evaluates whether live Kubernetes resource definitions match the target manifests in Git, Helm, or OCI.

• Health Status (Healthy, Progressing, Degraded, and others such as Suspended or Missing): Evaluates whether Kubernetes resources are operating as expected (for example, completing rollouts or passing readiness checks where applicable).

An application can be Synced but unhealthy, or OutOfSync while still serving traffic, which is why Argo CD tracks synchronization and health independently.

Configuring the Reconciliation Interval

Argo CD detects drift either through periodic reconciliation (120 seconds by default, plus jitter) or Git webhooks that trigger immediate reconciliation when changes are pushed. The interval is configurable in the argocd-cm ConfigMap:

# argocd-cm ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cm
  namespace: argocd
data:
  timeout.reconciliation: "120s"
  timeout.reconciliation.jitter: "60s"

Shortening the interval surfaces drift faster at the cost of more frequent polling load; setting timeout.reconciliation to 0disables polling entirely, relying solely on Git webhooks to trigger reconciliation.

What Happens When Someone Changes a Live Resource

Suppose an engineer changes a Deployment directly in the cluster using kubectl, increasing the replica count from three to five. Argo CD detects that the live resource no longer matches the version stored in Git and marks the application as OutOfSync. With selfHeal enabled, Argo CD reverts the count back to three on the next reconciliation.

Without selfHeal, the application stays OutOfSync indefinitely. The change is visible, but nothing acts on it until someone syncs manually or a new Git revision arrives.

That behavior is usually the right default. It is not always. Horizontal Pod Autoscalers, service meshes, and other controllers legitimately mutate live resources, and self-healing reverts each change on the next reconciliation while the controller reapplies it, producing a revert loop.

Self-healing is generally appropriate for stateless application resources. Stateful workloads, shared infrastructure, and anything touched by another controller need either ignoreDifferences or manual review before reconciliation.

Further Reading on Argo CD

Sync and drift are one layer of running Argo CD. The complete guide to Argo CD covers core concepts, architecture and components, deployment models, and the choice between running the control plane in-house and consuming it as a managed service.

For more guidance on security, deployment strategy, and GitOps implementation, explore these resources:

1. Argo CD: Up and Running (O'Reilly): A free ebook covering GitOps fundamentals and hands-on Argo CD usage for teams managing Kubernetes clusters without deep Kubernetes expertise.

2. Akuity Academy: Introduction to GitOps and Argo CD: A self-paced course on GitOps fundamentals and core Argo CD concepts.

3. GitOps Best Practices Whitepaper: A whitepaper on GitOps implementation patterns — templating, repo structure, CI/CD integration, and promotion with Kargo — from the creators of Argo CD and Kargo.