Skip to main content
Radar gives Argo CD and Flux a shared operational workspace. Instead of treating GitOps resources as generic CRDs, it resolves their sources, maps the resources they manage, explains unhealthy reconciliation state, and puts the appropriate controls next to the problem.
Radar GitOps fleet view with Argo CD Applications and Flux Kustomizations and HelmReleases

​
Start with the fleet

Open GitOps in the sidebar to see Argo CD Applications alongside Flux Kustomizations and HelmReleases. Each row shows the controller, source, destination, sync and health state, automation mode, and lifecycle state. Use search and filters to narrow the fleet by sync, health, project, namespace, labels, automation, or lifecycle. Radar resolves Flux source references to their repository URL, so both ecosystems are recognizable without opening the underlying CRD. Click a row to open its detail page. Every detail page has three top-level tabs:
  • Topology maps the GitOps resource to its sources, dependencies, and managed Kubernetes resources.
  • Resources lists the managed objects. The additional diagnosis available here depends on the controller and apply strategy.
  • Activity shows the reconciliation signal Radar can read from the controller resource.

​
Argo CD and Flux capabilities

The workspace is shared, but Radar does not pretend the two controllers expose identical data. For a screenshot-led Flux walkthrough, setup guidance, and Flux-specific limitations, see FluxCD UI and Kubernetes integration. For exact CRD and API coverage, see the GitOps coverage matrix.

​
Understand what an application manages

The Topology tab is the common visual model for both controllers. Switch between graph and table views, search the resource tree, or filter by kind, sync, health, role, and namespace. Radar follows Kubernetes ownership from the GitOps root through workloads, ReplicaSets, and Pods. It also understands controller-specific relationships:
  • Argo CD Applications connect to the resources reported in their managed-resource tree. Child Applications open as their own GitOps detail pages.
  • Flux Kustomizations and HelmReleases connect to their source, dependsOn dependencies, and managed resources discovered from Flux inventory or helm-controller labels.
Nested GitOps resources carry an Argo or Flux badge and open as their own GitOps detail pages rather than generic resource drawers. A lineage breadcrumb keeps the parent reachable as you move through nested Applications or a Flux dependency chain.

​
Diagnose the current state

The issue band at the top of a detail page translates controller state into an operator-facing explanation. It separates controller-specific diagnosis from shared lifecycle problems:
  • Argo CD - operation failures, Application conditions, unhealthy or missing children, drift with auto-sync disabled, and drift that persists after a successful automatic sync.
  • Flux - failed Ready, Healthy, Released, or TestSuccess conditions, plus stalled or actively reconciling state, with the controller’s message and affected source or dependency context preserved.
  • Both - pending deletion, finalizer ownership, deletion age, and controller health when Radar can read the controller Pods.

​
Per-resource health

Each managed resource shows a health value in the topology, the Resources tab, and the issue band. Radar labels where that value comes from:
  • Argo CD’s own verdict. Argo evaluates every managed resource it has a health check for and rolls the results into the Application’s health. Through Argo CD 2.x that per-resource result is also written into the Application object, and Radar shows it as is.
  • Argo CD’s verdict, read from its API server. Argo CD 3.0 changed the default so the controller no longer records per-resource health on the Application (controller.resource.health.persist in argocd-cmd-params-cm, now false). The Application still reports its overall health, but every managed resource is left without one. When Radar can reach argocd-server it asks for the same per-resource verdicts and shows those: with the Argo CD integration connected (Settings → Argo CD), or with no setup at all on installs that allow anonymous read (users.anonymous.enabled). Once an anonymous read has succeeded, that connection is the integration: Settings shows it as connected with no token needed, and the Git-rendered diff works over it too; a server that refuses the read stays “Not connected”. Radar accepts the answer only for the same Application (matching UID) and only when the Application deploys to the connected cluster. If the integration is set up and Radar still gets no usable answer — token rejected, server unreachable, a different install answering — the notice says so and why.
  • Radar’s own read. When Argo’s verdicts are neither on the Application nor reachable, Radar reads the live resources itself and reports what it finds: crash loops, image pull failures, failed Ready conditions, and the other problems its issues engine classifies. Those rows carry a Found by Radar marker, and a line above the issue band says the problems listed are Radar’s findings.
Radar only reports problems this way. It never marks a resource Healthy on Argo’s behalf, and a resource it has nothing on is shown without a health value. A resource Argo has no health check for can still show a Radar finding when it is unhealthy; the marker makes clear that this is Radar’s read, not a change in Argo’s verdict. An Application that deploys to another cluster gets neither: Radar reads only the cluster it is connected to, so it derives nothing for that Application and says so. Radar Cloud can connect both clusters and show the Application’s resources together. To see Argo’s per-resource verdicts instead of Radar’s read, connect Radar to your Argo CD server in Settings, or set controller.resource.health.persist: "true" in argocd-cmd-params-cm and restart the application controller. Radar switches to Argo’s values automatically either way. The Resources tab provides deeper per-resource investigation for Argo CD Applications. Radar shows recent Kubernetes events and computes field-level drift when desired state is available from the Argo CD API or a resource’s kubectl.kubernetes.io/last-applied-configuration annotation. Flux currently provides managed-resource inventory and live state, but not Git-to-live field diffs or the same per-resource event enrichment.

​
Review activity

Activity reflects the history each controller exposes:
  • Argo CD shows the current operation and deployment history with timestamps, revisions, initiators, and rollback actions.
  • Flux shows the current condition transitions and the applied or attempted revision. It is not a complete historical operation log.
Reconciliation-related Kubernetes events also appear in the Timeline, where clicking an Application, Kustomization, or HelmRelease opens its GitOps detail page.

​
Operate the controller

Radar uses the operation appropriate to the selected resource. Keyboard shortcut s opens Argo CD Sync or triggers Flux Reconcile.

​
Argo CD

​
Flux

Mutating operations are disabled while a resource is terminating. The same operations are available to AI clients through Radar’s MCP server, with Kubernetes RBAC as the enforcement boundary.

​
GitOps context across Radar

GitOps ownership remains visible outside the workspace:
  • Resource drawers link tracked Kubernetes objects back to their owning Application, Kustomization, or HelmRelease.
  • Topology and Timeline open GitOps resources in their dedicated detail pages.
  • Helm releases installed by Flux show their owning HelmRelease and warn that direct Helm changes may be reconciled back.
  • Cluster Audit flags resources stuck terminating using the same lifecycle thresholds as GitOps detail pages.

​
Permissions and scope

Read-only visibility requires access to the Argo CD or Flux CRDs. Operations require the corresponding patch permissions. Canonical Git-rendered Argo CD diffs require a configured Argo CD API integration and access to its managed-resource data. See in-cluster configuration for Helm values and custom RBAC rules. Radar builds GitOps relationships from the cluster it is connected to. Argo CD hub-and-spoke installations cannot show Application-to-workload edges when the controller and workloads live in different clusters. Flux normally reconciles its local cluster, so its relationships are usually available.

​
Go deeper