> ## Documentation Index > Fetch the complete documentation index at: https://radarhq.io/docs/llms.txt > Use this file to discover all available pages before exploring further. # Applications view - browse a cluster by app > Group a cluster's workloads into the application they belong to - resolved from ownership, GitOps, Helm, and labels - with a workload rail, topology, and search. Open source and Cloud. 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: ```yaml theme={null} 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](/cloud/applications) 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](/cloud/applications) in Radar Cloud. ## See also * [Topology](/features/topology) - the graph the per-app view scopes down. * [GitOps](/features/gitops) - the Argo CD / Flux applications that feed app grouping. * [Fleet Applications](/cloud/applications) - the same view folded across your fleet (Cloud).