Skip to main content
A deployable application isn’t a Kubernetes object - there’s no App kind. What you call “the billing app” is scattered across Deployments, a worker, a CronJob, a Service, maybe an Ingress, possibly across namespaces. The Applications view (/applications, or g a) reconstructs that: it groups a cluster’s workloads into the app they belong to, so you browse by application instead of by raw kind. Radar's Applications view - a cluster's apps grouped from workload evidence, with Source, Class, and Environment filters and per-app version, readiness, and workload counts

​
How apps are resolved

Radar resolves app membership from real evidence rather than forcing you to label everything. Each app row carries a Source facet so you can filter by where the grouping came from:
  • Argo CD / Flux - the GitOps Application, ApplicationSet, or Flux source that manages the workloads.
  • Helm - the release the workloads belong to.
  • Label - common app labels (app.kubernetes.io/name, app.kubernetes.io/instance, app.kubernetes.io/part-of, app).
  • Ungrouped - workloads Radar couldn’t confidently attribute.
The workload is always the addressable thing; app identity is grouping evidence layered on top, never a replacement for it.

​
When inference isn’t enough

Grouping is heuristic by nature, and heuristics occasionally guess wrong. When they do, you don’t fight the inference - you declare the answer. Set the app.skyhook.io/app annotation on the workloads that make up the app, using the same value on each, and Radar groups by that explicit identity: 
metadata:
  annotations:
    app.skyhook.io/app: billing
An identity chip on each row shows how confident Radar is in the grouping - emerald when the identity is declared (the annotation, or a GitOps source path), neutral when it’s a heuristic match - with an evidence tooltip explaining the call. A declared identity is also what lets the fleet view fold the same app across clusters; a per-cluster name alone can’t.

​
Per-app detail

Open an app and you get an application shell - identity, a context strip, and a workload rail listing the app’s members - wrapped around the same runtime tabs you get on any resource: Overview, Topology, Timeline, Logs, Metrics, YAML. The topology is scoped to the app, so you see how its workloads wire together without the rest of the cluster’s noise. Hovering a workload highlights it and its resources across the graph while the rest dim; related resources open in place in a drawer. The argocd application in Radar - the workload rail on the left and the app-scoped topology graph, with argocd-server highlighted and the other workloads dimmed

​
Finding apps

  • Search filters apps by name; keyboard navigation (j / k, Enter) moves through the list and opens an app without leaving the keyboard.
  • The view sits in the left nav rail alongside every other view - jump to it with g a.

​
Across clusters

The single-cluster view above is the open-source and per-cluster Cloud surface. To fold the same app across the clusters and environments it runs in - one row per app, with version skew and promotion lag - see Fleet Applications in Radar Cloud.

​
See also

  • Topology - the graph the per-app view scopes down.
  • GitOps - the Argo CD / Flux applications that feed app grouping.
  • Fleet Applications - the same view folded across your fleet (Cloud).