Argo CD / Desired state and evidence foundations / Lesson 5

Sync status and resource health are separate observations

Interpret OutOfSync, Synced, Progressing, Degraded, and unknown evidence without overclaiming.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Distinguish desired-versus-live comparison from resource health.
Keep operation result, health freshness, and user verification separate.

Sync status describes a comparison contract

An Application’s sync status summarizes desired and live comparison under Argo CD’s normalization, tracking, and diff rules. Synced does not mean every workload is ready, and OutOfSync does not mean every resource is unavailable. Parcel can have a healthy old Deployment while a desired image change remains unapplied. It can also match desired manifests while the workload cannot start. Always ask which revision and generated inputs were compared and whether comparison completed successfully. Unknown or comparison-error evidence should not be converted into an assumed match.

Health depends on resource-specific semantics

Resource health evaluates observations appropriate to each supported kind or configured customization. Deployment rollout fields, Job completion, and other resource conditions answer different questions. A healthy child under one rule does not prove an external carrier integration or correct application data. Health can be stale or unavailable if observations fail. Custom resources may need explicit assessment and careful interpretation. Document the health contract and its version assumptions rather than treating every green icon as a universal end-to-end success signal.

Read combinations instead of one badge

The conceptual table below shows why two status dimensions matter. It is not observed Argo CD output and does not claim every combination appears identically in every interface. Operation phase is another dimension: a sync request may be running or failed even while some resources remain healthy. Preserve conditions and bounded messages that explain generation, comparison, permission, or workload issues. A last successful operation from an older revision does not establish that the current desired revision has been adopted.

text A conceptual status-combination table

OutOfSync + Healthy: an old or changed state may still serve
Synced + Degraded: desired comparison matches, resource behavior fails
Synced + Progressing: adoption may still be converging
Unknown evidence: investigate observation or generation limits

These interpretations are conditional teaching examples, not measured cluster states. They do not replace per-resource conditions, actual revision identity, operation details, or user verification.

Do not collapse missing evidence into healthy

The complete local model requires a matched comparison and a healthy resource observation before labeling a candidate ready for a separate user check. It keeps absent health as unknown. This does not implement Argo CD’s status aggregation or resource-health algorithms and cannot authorize a release. Its value is making an incomplete observation visible. Real verification also needs source and target identity, data freshness, required resource coverage, and the specific user behavior the release is meant to preserve.

python A synthetic evidence-classification model

def next_check(sync, health):
    if health is None:
        return "unknown"
    if sync == "Synced" and health == "Healthy":
        return "verify user outcome"
    return "inspect resource evidence"
print(next_check("Synced", None))
print(next_check("Synced", "Degraded"))
print(next_check("Synced", "Healthy"))

Expected output

unknown
inspect resource evidence
verify user outcome

Only declared strings are evaluated. The program queries no resource and does not reproduce Argo CD aggregation or a production release gate.

Choose the next investigation from the failed boundary

For generation or comparison errors, inspect source and rendering evidence before workload health. For an apply rejection, inspect the exact resource and authorization or schema condition. For a progressing or degraded workload, use the owner’s existing resource observations to distinguish readiness, scheduling, image, configuration, and dependency failures. Do not respond to every state with another sync. A retry can repeat side effects and cannot repair a missing application prerequisite by itself. Retain a concise timeline so the final outcome can be connected to the intended revision.

Common errors and fixes

Synced is reported as proof that the application works for users.

Why it happens: Comparison evidence was stretched into runtime and business correctness.
How to fix it: Verify resource health and the relevant user journey separately.
Prevent it next time: State what each status dimension proves and excludes.

A healthy old workload is described as adoption of the new revision.

Why it happens: Health was read without desired and observed identity.
How to fix it: Match revision, sync, operation, and runtime evidence.
Prevent it next time: Retain source and target identities with verification.

Missing health data is treated as zero errors.

Why it happens: Unknown observation was silently converted into success.
How to fix it: Report unknown and investigate the evidence path.
Prevent it next time: Define missing-data behavior in release policy.

Check your understanding

1. Can Parcel be OutOfSync while its existing service still responds?

Show worked solution

Yes. A healthy existing state can differ from the desired revision. That response does not prove the requested change was adopted. Check the comparison and actual resource identity alongside the user observation.

2. Why does the local model say verify user outcome after Synced and Healthy?