How does Argo CD's sync process work — desired state vs live state?

Argo CD's sync process is a six-step reconciliation cycle executed by the Application Controller on every polling interval (default: 3 minutes) or on webhook notification.

1. Clone and render: The Repository Server clones (or updates from cache) the Git source at the specified targetRevision. It runs the appropriate tool — kustomize build, helm template, or reads plain YAML — to produce a set of Kubernetes resource manifests.
2. Fetch live state: The Application Controller calls the Kubernetes API to list the current state of all resources in the Application's destination namespace that are labeled as managed by this Application.
3. Compute diff: Argo CD performs a three-way diff between (a) the last-applied configuration, (b) the current live state, and (c) the desired state from Git. Resources present in Git but not in the cluster are marked as missing. Resources in the cluster but not in Git are marked as extra (candidates for pruning).
4. Sync decision: If any resource differs, the Application status is set to OutOfSync. If syncPolicy.automated is configured, the sync proceeds immediately. Otherwise, a human must trigger it via UI, CLI, or webhook.
5. Apply: Argo CD applies the desired manifests using server-side apply. Pre-sync and sync hooks execute in their designated phases.
6. Update status: Application sync status becomes Synced or SyncFailed. Health status (Healthy / Degraded / Progressing / Missing) is evaluated by checking the readiness conditions of the deployed resources.

# Example: Application status after a partial sync failure
status:
  sync:
    status: OutOfSync
    revision: "abc1234def5678"
  health:
    status: Degraded
  conditions:
    - type: SyncError
      message: "Failed to apply deployment.apps/frontend: field is immutable"
      lastTransitionTime: "2026-04-22T10:00:00Z"