Argo CD 3.6 makes progressive sync observable and broadens its health checks
Argo CD 3.6.0-rc1, released September 16, 2026, adds metrics and conditions to ApplicationSet progressive sync and expands the health-check library — CloudNativePG, cert-manager, Prometheus Operator, Kyverno. Teams that roll out changes in waves across clusters should plan the upgrade once the stable release lands.
September 16, 2026. Argo CD ships v3.6.0-rc1, the first draft of the next minor release of the reference GitOps tool. Progressive sync: ApplicationSets gain dedicated metrics and conditions. Health checks: the library grows by a dozen resources, from CloudNativePG to cert-manager through the Prometheus operator. Why it matters: teams that roll out changes in waves across clusters stop flying their deployments blind.
Progressive sync goes from mechanism to observable
Progressive sync is one of Argo CD’s most strategic capabilities: it rolls an update wave by wave across a set of clusters, stopping the moment a step fails. It is the mechanism that turns a plain Git sync into a deployment strategy worthy of a multi-environment canary. Its historical weakness was not functional but observational — mid-wave, it was hard to tell how many applications had already been refreshed, why the progression had paused, or whether a controller was starting to choke.
3.6 targets exactly that blind spot. ApplicationSets now expose progressive-sync metrics, plus a counter of the application refreshes the ApplicationSet triggers during a roll. One contributor adds annotations on applications to force a reconciliation before proceeding with the wave — a way to guarantee an intermediate state is actually taken into account before moving to the next step. Finally, progressive-sync scenarios are surfaced in resource conditions as human-readable reasons and messages, and the ApplicationSet controller exposes rate-limiter flags on its work queue.
In practice: a team rolling an update across twenty clusters can now see in Prometheus and in the resource status where the wave stands, how many applications have synced, and why progression stopped. Progressive sync becomes something you observe and steer with the same discipline as an ordinary application deployment.
How progressive sync actually works
For scale, it helps to recall the mechanics. Argo CD’s progressive sync relies on a RollingSync strategy declared at the ApplicationSet level: you divide the fleet into steps, each targeting a subset of clusters through matchExpressions, and the controller moves to the next step only once the previous one is synced and healthy.
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: fleet-rollout
spec:
strategy:
type: RollingSync
rollingSync:
steps:
- matchExpressions:
- key: env
operator: In
values: [dev]
- matchExpressions:
- key: env
operator: In
values: [staging]
generators:
- clusters: {}
template:
metadata:
name: "{{name}}-app"
spec:
project: default
source:
repoURL: https://github.com/example/fleet.git
targetRevision: main
destination:
server: "{{server}}"
namespace: defaultWhat was missing was visibility. Rolling a wave across twenty clusters without metrics is flying blind — you know it is moving, not where it stalls. The progressive-sync metrics added in 3.6 close exactly that gap, and the forced-reconciliation annotations answer a finer need: making sure an intermediate state has actually been reconciled before the next wave is allowed. That is the difference between “deploying in steps” and “deploying in steps while knowing where you are.”
Health checks for the operator ecosystem
The other half of the release is a sharp extension of the health-check library — the rules that tell Argo CD when a custom resource is genuinely “healthy”, beyond a bare Synced status. 3.6 adds checks for:
- CloudNativePG: the operated PostgreSQL database, its backups and hibernate/rehydrate actions;
- cert-manager: CertificateRequests and trust-manager Bundles;
- Prometheus Operator: Alertmanagers and ThanosRulers;
- Kyverno, Kro, the Gateway API TLSRoute, AWS ACK resources, FlinkSessionJob and Medusa jobs.
The logic is clear: modern clusters are increasingly governed by operators that create CRDs, and a GitOps tool that cannot read the real state of those resources marks them “synced” while they are actually failing. Adding CloudNativePG or cert-manager to the library lets Argo CD halt a wave when the database cluster or certificate issuance is not ready, rather than rolling on over a broken foundation.
A slightly firmer delivery chain
The security of the delivery pipeline is not left behind. The project enables Zizmor in its CI to enforce secure configurations on its own workflows, and makes the minimum TLS version of the Dex front-end configurable, along with the Dex storage type via the argocd-cm ConfigMap. On the distribution side, images and binaries remain signed by cosign and shipped with SLSA Level 3 provenance.
Operationally, the CLI learns to exclude the status field from an argocd admin export, and the controller accepts metrics and condition flags through argocd-cmd-params-cm. These are comfort details, but they point in one direction: 3.6 treats operating Argo CD as a first-class problem, not a detail left to integrators.
Why this release matters for GitOps at scale
The 3.x line has moved fast: 3.4 and 3.5 landed earlier in 2026, each tightening progressive delivery and observability in turn. 3.6 continues the same vector — no single headline feature, but a steady accumulation of the small things that make GitOps safe at scale. That trajectory matters because Argo CD has become the default GitOps controller for a large share of Kubernetes estates, and every minor release now ripples through thousands of clusters.
The hibernate/rehydrate actions for CloudNativePG capture the depth this release reaches: beyond a bare health status, Argo CD now understands the full life cycle of an operated PostgreSQL cluster — parking it to cut costs, then waking it before a wave. That is what stops a team from deploying onto a database that is “synced” but actually asleep or restoring. The health-check library stops being a convenience and becomes a guardrail: it converts a Git status — “the resource exists” — into a real state — “the resource is ready”.
Because those checks are declarative and versioned like the rest of the manifest, they travel with the application from cluster to cluster, with no ad hoc scripting. For a platform team, that is the guarantee the same rigour applies to the first cluster and the two-hundredth alike — the property that separates a tool you use from a tool you hand your fleet to.
The operational changes are quieter but point the same way. The CLI can now strip the status field from an argocd admin export, which matters when you are shipping configuration between environments and do not want live state leaking into your Git tree. The controller’s new metrics and condition flags, set through argocd-cmd-params-cm, move tuning out of source-code forks and into configuration. None of these will make a conference slide. Together, they are what let a team run GitOps at scale without hiring it out — and what makes the 3.6 upgrade a low-risk, high-leverage move.
There is a reason the security touches matter too: enabling Zizmor in the project’s own CI and making Dex TLS configurable are small gestures individually, but they signal that the project treats its own delivery chain with the same severity it now expects from its users. For an organisation whose entire change pipeline funnels through Argo CD, that posture is worth more than any single feature.
Verdict
Argo CD 3.6 is a maturity release: it does not reinvent the product, it makes existing features measurable and steerable and widens health-check coverage to the operator ecosystem that dominates 2026 clusters. If you run progressive sync — or plan to — this is the release that gives you the metrics and conditions you need to operate it in production without a safety net; plan to switch as soon as the stable release ships. If you are not rolling in waves yet, the decisive argument lies elsewhere: the expanded health-check library protects everyone, including teams that just sync, by stopping Argo CD from declaring a CloudNativePG or cert-manager resource healthy when it is not. If you are still weighing Flux against Argo CD, this release will not settle it — but it widens the gap on one specific point: how deeply the tool reads the true state of your CRDs.