In Argo CD, an Application reports both a sync status and a health status. What does each one tell you, and what values can each take?

## Two axes, not one Every Argo CD Application carries two separate verdicts, and confusing them is the single most common misunderstanding in ArgoCD interviews. - **Sync status** answers *"does the cluster match Git?"* - **Health status** answers *"is what is running actually working?"* They are computed by different machinery, they change at different times, and neither implies the other. ## Sync status Argo CD periodically fetches the Application's source (a Git repo path, a Helm chart, an OCI artifact) at `targetRevision`, renders it into plain Kubernetes manifests, and diffs that desired state against the live objects it reads from the destination cluster. The result is one of: - `Synced` — every declared object matches its rendered manifest. - `OutOfSync` — at least one object differs, is missing, or (with pruning visible) exists in the cluster but not in Git. - `Unknown` — the comparison could not be made, for example the repo could not be fetched. Sync status is about **intent delivery only**. A manifest that applies cleanly and then crash-loops is still perfectly `Synced`. ## Health status Health is assessed per resource. Argo CD ships health checks for the common built-in kinds and derives the verdict from the object's own `status` subresource — for a Deployment it looks at `status.observedGeneration`, the updated/available replica counts and the `Progressing` condition; for a Service of type `LoadBalancer` it looks for an assigned ingress address; for a Job it looks at completion. The possible values are: - `Healthy` — the resource reports itself as fully operational. - `Progressing` — it is not there yet, but it is still working on it (a rollout in flight). - `Degraded` — it failed: replicas never became available, the progress deadline was exceeded, a Job failed. - `Suspended` — deliberately paused or suspended, such as a suspended CronJob or a paused rollout. - `Missing` — declared in Git but not present in the cluster. - `Unknown` — the health check could not reach a verdict, or errored. Custom resources with no registered check are treated as `Healthy` by default, which is why a CRD-heavy Application can look green while its controller is still provisioning something. ## Rolling up to the Application The Application's health is an aggregate over the resources in its tree: any `Degraded` resource degrades the whole Application, and a `Progressing` resource keeps it `Progressing`. That aggregation is what a `Sync` operation with health checking waits on — the operation is not "done" the moment `kubectl apply` returns, it is done when the affected resources report healthy. ```bash argocd app get guestbook # Health Status: Degraded # Sync Status: Synced to main (9a64214) ``` ## The four combinations you should be able to read | Sync | Health | What happened | |------|--------|----------------| | Synced | Healthy | Steady state — the cluster matches Git and everything reports well. | | Synced | Progressing | Argo applied the new manifests and the rollout is still in flight. | | Synced | Degraded | **Argo did its job; the change is bad.** Git says X, X is running, X does not work. | | OutOfSync | Healthy | Something drifted or a new commit landed; the currently-running version is fine. | The third row is the production surprise the topic exists for. GitOps reconciliation guarantees convergence to the declared state — it makes no claim that the declared state is *good*. Argo CD does not automatically revert a `Degraded` Application; getting back to a working version means changing Git (or using a progressive-delivery controller that can abort on its own). ## Why interviewers ask Because the answer reveals whether a candidate treats the tool as a deployment button or as a reconciler. "It says Synced, so we shipped it" is a statement about YAML delivery. Knowing that health is a second, independently computed, per-kind assessment — and that it can be wrong or absent for custom kinds — is what separates someone who has operated Argo CD from someone who has clicked its UI.