Your software, not a pile of ReplicaSets.
Radar folds related workloads into the applications they actually form - using GitOps, Helm, label, and naming evidence - so the first thing you see is your software, not the objects it decomposes into.
Kubernetes shows you objects. You think in apps.
Nobody deploys “a Deployment.” You deploy checkout, which happens to decompose into a Deployment, a Service, an Ingress, a ConfigMap, and an HPA. Every object browser - Lens, k9s, the stock dashboard - shows you the decomposition and leaves the recomposition to you.
So “is checkout healthy in prod?” becomes a mental join across five kinds - and because dev, staging, and prod each run their own copy, every list you look at is three times longer than your actual software.
Radar recomposes the apps for you, from the evidence already in the cluster: GitOps ownership, Helm releases, labels, and naming. checkout-web, checkout-worker, and checkout-redis share a Helm release, so they fold into one checkout row - health rolled up, and the dev, staging, and prod copies folded under it. No labeling campaign required first.
One row per application.
Evidence-based folding
App rows resolve from GitOps ownership (Argo CD, Flux), Helm release membership, common app labels, and naming - and every row carries a Source facet showing which evidence grouped it, so the folding is inspectable, not magic.
Health rollup and class
Every app carries its own health rollup across the workloads inside it, a class (Service / Worker / Job), and an app-vs-add-on classification that separates your software from the platform's.
Environment folding with skew
Instances of the same app across dev, staging, and prod fold into a single row - with a skew badge when one environment falls behind another.
Filter like a list
Slice by availability, class, type, environment, or grouping source (Argo CD / Flux / Helm / Label / Ungrouped). Built on the same list primitives as Issues and Checks, so the filters behave the way you already learned.
From app to objects
Open any app for its app-scoped topology and related-resource YAML views - the object level is one click away, scoped to the app you actually care about. The workload stays the addressable thing; app identity is evidence layered on top.
“staging is behind dev” - said out loud.
When the copies of an app diverge - dev moved, staging didn't - the folded row wears an amber skew badge naming exactly which environment fell behind. Promotion lag stops being something you discover during an incident and becomes something you scan for in a list.
It's in the hero screenshot above: skyhook-connector and billing both carry a live staging is behind dev badge from a real cluster.
The badge is computed from the folded instances' running versions - no release spreadsheet, no asking in Slack which environment got the deploy.
When the heuristic guesses wrong, you outrank it.
Grouping is heuristic by nature, and heuristics occasionally guess wrong. You don't fight the inference - you declare the answer: one annotation, same value on each workload, and Radar groups by that explicit identity over anything it inferred.
Every row carries an identity chip - 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. Declared identity is also what lets Radar Cloud fold the same app across clusters.
metadata:
annotations:
app.skyhook.io/app: billingApache 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 folds applications across your whole fleet.
The same view, spanning every connected cluster: dev, staging, and prod of an app fold into one row even when they run in different clusters, and search works across applications - not just clusters.
See the OSS vs Cloud comparisonQuestions we get about Applications.
How is this different from the app.kubernetes.io labels I already have?
What if something is grouped in a way I don't expect?
app.skyhook.io/app annotation with the same value on each workload of the app, and Radar groups by that declared identity. An identity chip on every row shows whether the grouping is declared (emerald) or a heuristic match (neutral), with an evidence tooltip explaining the call.Does the Applications view replace the resource browser?
Is this OSS or Radar Cloud?
More of what Radar does in the same binary.
Issues & root cause
Failures grouped by subject, folded to the cause, with blast radius.
GitOps for Argo + Flux
Fleet + per-app diagnosis with field-level drift, controller attribution, and lifecycle awareness.
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.
The list you actually think in.
The objects are still there when you need them. Start from the apps.
Apache 2.0 OSS · Unlimited clusters self-hosted · Hosted free tier for up to 3 clusters