OutOfSync is easy. Diagnosing it isn't.
Argo CD and Flux in one fleet view, a per-app detail page that explains why a reconcile is stuck, and lifecycle awareness so a half-deleted app doesn't masquerade as a sync problem.
“OutOfSync.” That's it. That's the answer.
A GitOps controller's job is to make live state look like Git. When it can't, the status chip says OutOfSync - and the why is spread across tools. The Argo UI shows the diff - for Argo. The events of the resource that actually failed, the controller holding a finalizer, and your Flux half still mean kubectl describe, controller logs, and a second UI. Each tool holds a piece; none has the story.
When the resource is also being deleted, it's worse: the controller's last-observed status still says “Syncing · Progressing” even though the reconciler hasn't touched it since deletion started. You spend ten minutes investigating a routine sync problem on a zombie the cluster is actively tearing down.
Radar puts the diagnosis on the page. Field-level drift, the events of the resource that failed, parsed operation errors, and - for stuck deletions - the name and pod state of the controller holding the finalizer. All derived from data the controllers already publish.
Six kinds of stuck, each named.
Every issue class the detail page surfaces, with the cause attribution it carries.
Operation failures, in plain English
The parser recognizes 10+ Argo failure patterns - annotation-too-large, hook failure, admission-webhook denial, RBAC, immutable field, connectivity - and rewrites each into a cause you can act on instead of a wall of controller output.
Stuck-drift loop detection
Sync succeeded, auto-sync is on, the app is still OutOfSync: something is mutating resources after every apply. Radar flags the loop and names the likely culprits - a mutating webhook, a sibling controller, a schema migration.
Manual drift called out
Drift with auto-sync disabled means nothing will reconcile until someone clicks Sync. Radar says exactly that, so you stop waiting for a controller that was never going to act.
Application conditions, typed
Argo reports an app's health through "Application conditions." Radar surfaces them as typed issues with severity - ComparisonError (check your repo credentials), OrphanedResourceWarning, InvalidSpecError - instead of strings buried in status YAML.
Per-resource health, deduped
Degraded or Missing children each get their own issue - deduplicated against any operation failure that already named the same resource, so one broken Deployment doesn't render three ways.
Terminating doesn't lie
A resource pending deletion shows a [Terminating] chip instead of stale Sync/Health badges. Severity ramps with age, and past 30 minutes the issue names the controller holding the finalizer and reports its pod state.
Flux, first-class
FluxCD Kustomizations and HelmReleases with the same treatment Argo gets: two broken reconciles caught mid-loop, one suspended, and a Terminating zombie pending deletion for 8 days - filtered out of a fleet that also runs ten Argo apps in the same list.
One page, one answer.
Click any Application, Kustomization, or HelmRelease in the fleet view. The header splits config (Source, Path, Destination, Sync mode) from deployment state (revision, age, resource health), the issues band names what's wrong, and three tabs - Topology, Resources, Activity - carry the detail.
The managed graph
Application root plus every managed resource, with ownership edges (Service → Deployment → ReplicaSet → Pod). App-of-apps children and nested Kustomizations render as portal nodes with a lineage breadcrumb. Mark individual resources here and sync only those.
Per-resource drift + events
Sync chip, health chip, a per-field drift summary expanded inline (spec.replicas 1 → 3, which fields moved, desired vs live) - with a pointer to argocd app diff when you want the full line-by-line - plus the five most recent events for that resource.
Operation history + rollback
Deploy timestamps, the git revision deployed, who initiated the sync - human or automation - and a per-revision Rollback button for Argo. In-flight operations pin to the top and the page tracks them live.
Everything you'd reach for the CLI to do.
Argo CD
Sync with the full options dialog - prune, dry-run, apply-only, force, replace, server-side apply, with PreSync/PostSync hooks preserved on force. Refresh and hard refresh. Terminate an in-flight operation. Rollback to any history entry. Suspend auto-sync and get your prune/selfHeal settings back on resume.
Flux
Reconcile a Kustomization or HelmRelease on demand, reconcile the source first when the repo moved, suspend and resume via spec.suspend. Source CR drawers show every consumer, so you know what a source edit will touch before you make it.
Keyboard-first
s to Sync or Reconcile, r to Refresh, Shift+R for hard refresh, t to Terminate an in-flight op. Built for hands that know the argocd / flux CLIs.
Guarded on zombies
On a Terminating resource, Sync / Reconcile / Suspend / Rollback disable with a reason; Refresh and Terminate stay available. The same gate applies over MCP - manage_gitops returns a structured error, so an AI assistant won't suggest syncing a half-deleted app.
GitOps context follows you across Radar.
Resource drawer
Any resource carrying Argo's tracking-id annotation or Flux's owner labels gets a clickable Managed by chip - one click to the owning Application or Kustomization. Deliberately not driven by the generic app.kubernetes.io/instance label, which would false-positive every plain Helm install.
Topology + Timeline
Click an Argo Application or Flux Kustomization / HelmRelease node in the main topology graph - or its lane label in the timeline - and Radar opens the GitOps detail page directly, not the generic resource drawer.
Helm view
Releases installed by Flux's helm-controller carry a Flux badge and a Managed by Flux · ns/name link - with a warning that a manual helm upgrade would be reverted at the next reconcile.
Home dashboard
A GitOps Controllers card rolls up Argo CD and Flux controller pod health, so “is the controller even running” is answered before you open a single app. Hidden entirely on clusters without GitOps.
Hub-and-spoke ArgoCD is only half-visible.
Radar draws Application-to-resource edges only when the controller and the managed resources live in the same cluster. Connected to an ArgoCD hub that deploys elsewhere, you'll see the Applications but not their managed trees. Flux typically runs in-cluster, so Flux setups usually get the full graph.
Apache 2.0. Yours to inspect, fork, or self-host.
Radar's source is on GitHub. Every feature on this page is in the binary you install with brew install. No telemetry, no mandatory login, no cluster data out. The one outbound call is an anonymous version check when the UI opens. If we ever change that, you'll see it in a diff first.
Radar Cloud rolls GitOps up across every cluster.
Radar OSS connects to one cluster at a time and surfaces its Argo / Flux state. Radar Cloud shows every ArgoCD and Flux application across your whole fleet in one list - drill into any of them with full single-cluster visualization, and use cross-cluster compare to spot version and config drift between environments.
See the OSS vs Cloud comparisonQuestions we get about the GitOps view.
Does Radar support both ArgoCD and Flux?
Does Radar need the Argo API server or a Flux webhook?
Can I sync and reconcile from Radar, or is it read-only?
How does Radar explain why an app is OutOfSync?
argocd app diff for the full line-by-line), recent events attach to the resource that caused them, operation failures are parsed into plain English, and a stuck-drift-loop detector flags apps that sync successfully but immediately drift again. Sync failures also surface in Radar's Issues queue with cause and remediation.What does Radar Cloud add for GitOps?
More of what Radar does in the same binary.
Issues & root cause
Failures grouped by subject, folded to the cause, with blast radius.
Applications view
Workloads folded into the apps they form, with health rollups and env skew.
Live topology graph
Every resource and connection, laid out by ELK.js, updated via SSE.
Event timeline
Every K8s event and resource change, retained past the 1-hour TTL.
Stop staring at “OutOfSync.”
Radar names the cause inline - drift, event, finalizer, controller - so you can fix it instead of guessing.
Apache 2.0 OSS · Unlimited clusters self-hosted · Hosted free tier for up to 3 clusters