> ## 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 across clusters (fleet view) > Fleet Applications groups workloads by the app they belong to and folds each app across the environments and clusters it runs in - one row per app, with version skew and promotion lag at a glance. The fleet **Applications** view (`/fleet/applications`) groups deployable software by the app it belongs to, then folds the same app's instances across clusters and environments into one row. It answers "where does `payments-api` run, and is every environment on the same version?" without opening each cluster. This is the **fleet** Applications view, which folds each app across clusters. For the single-cluster view in open-source Radar (and per-cluster in Cloud), see [Applications](/features/applications). ## How apps are resolved Radar resolves app rows from real evidence - workload ownership, GitOps Applications, Helm releases, and labels - rather than a single annotation you have to set. Each row carries a **Source** facet so you can tell where the grouping came from: `Argo CD`, `Flux`, `Helm`, `Label`, or `Ungrouped`. The instance is always the addressable thing. App identity is grouping evidence layered on top, never a replacement for the underlying workload. ## Grouping across environments Instances of the same app - the copies running in dev, staging, prod, and across clusters - fold into one row, with a cell per environment. A `koala-backend` running in staging and autopush on one cluster and prod on another collapses to a single row. * An **identity chip** shows how confident Radar is in the grouping - **emerald** when the app identity is declared, **neutral** when it's a heuristic match - with an evidence tooltip explaining the call. * Text search auto-expands a folded row into its hidden instances; instance rows are always one chevron away. * Clicking an environment cell drops you into that specific instance. Environment is resolved in order: an environment you've set explicitly on the cluster, then a namespace-name heuristic (rendered `~staging` and marked *inferred*), then unlabeled. ## Promotion lag and version skew * **Promotion lag** renders between ranked environments whose versions can be ordered - so you can see prod trailing staging at a glance. * A **per-instance skew** chip stays amber when the *same* app runs different versions within one environment across clusters - that's real drift. Different versions across *different* environments (dev ahead of prod) read as healthy promotion state, not an alert. ## Per-app detail Opening an app gives you an application shell - identity, context strip, and env / instance selectors - wrapped around the same runtime tabs you get on any single resource: **Overview, Topology, Timeline, Logs, Metrics, YAML**, served live through the cluster's own Radar. Related resources open in place in a drawer. ## Coverage and offline clusters Like every fleet page, Applications reports per-cluster status in the top bar. Scope to a cluster whose tunnel is down and the view says so plainly - "*cluster* isn't reporting - the tunnel is down" with a **View clusters** action - rather than implying the cluster runs nothing. ## See also * [Fleet views](/cloud/fleet-views) - the other cross-cluster aggregates (Issues, Search, Checks, Packages). * [GitOps](/features/gitops) - the Argo CD / Flux applications that feed app grouping. * [Connecting a cluster](/cloud/connect-cluster) - what makes a cluster report into the fleet.