Radar

curl -fsSL https://get.radarhq.io | sh && kubectl radar

"Have Radar deployed at work. As far as Kubernetes dashboards go, this is one of the best." — u/TheRealNetroxen

Then run:kubectl radar. Quick install, PowerShell, Homebrew, and Scoop also set up theradarshorthand. Krew and direct downloads usekubectl radarunless you add your ownradarsymlink.

scoop bucket add skyhook https://github.com/skyhook-io/scoop-bucket scoop install radar

irm https://get.radarhq.io/install.ps1 | iex

Native desktop app — no terminal needed.

brew install --cask skyhook-io/tap/radar-desktop

scoop bucket add skyhook https://github.com/skyhook-io/scoop-bucket scoop install radar-desktop

Deploy to your cluster for shared team access:

helm repo add skyhook https://skyhook-io.github.io/helm-charts helm install radar skyhook/radar -n radar --create-namespace

Chart supports optional Gateway APIHTTPRoutegeneration. EnablehttpRoute.enabled, setparentRefs, and usehttpRoute.rulesfor multiple path prefixes, per-route timeouts, filters, or custom backends.hostnamesdefaults to an empty list, andapiVersioncan be overridden for older Gateway API installations. The generated default route has no chart-imposed timeout, so the Gateway deployment default applies. SethttpRoute.defaultTimeoutfor an explicit timeout; custom rules can define their owntimeouts.

ingressandhttpRouteare mutually exclusive: enabling both stops the install with an error, so enable only one. WhenhttpRouteis enabled you must set at least oneparentRefsentry (the Gateway the route attaches to); otherwise the install fails instead of creating an HTTPRoute that is attached to no Gateway.

# Opens browser automatically kubectl radar # Quick install, PowerShell, Homebrew, and Scoop also set up the bare command radar

To inspect an in-cluster Radar Cloud installation without changing it:

radar cloud status radar cloud status --context my-cluster radar cloud status --context my-cluster --namespace radar --release radar

The command reports installation ownership, chart and image, agent readiness, and Cloud configuration without printing the connection token. Passing both--namespaceand--releaseselects an exact installation. Live tunnel status is reported by Radar Cloud using the token in the referenced Kubernetes Secret. If the Secret or Hub is unavailable, local installation diagnostics still run. Interactive terminals use restrained status colors; setNO_COLOR(or pipe the output) for plain text. URLs, tokens, and suggested commands remain unstyled.

Tuning for slow or high-latency clusters

The default deadlines (30 s context switch, 5 m first-paint backstop, 5 s namespace LIST, 20 scope candidates) are tuned for healthy clusters reached over fast, low-latency connections. They are too tight for clusters reached over SSH tunnels, geographically distant control planes, or accounts subject to API-server throttling, where they surface as one of three symptoms:

- "Context switch timed out" toasts when the cache eventually does sync
- "Limited list — RBAC doesn't allow listing all namespaces" even though the account has cluster-wide list permission (the LIST timed out, not RBAC)
- Kinds silently marked denied because the namespace they live in fell past the 20-entry candidate cap

Widen the four flags via CLI or via the matching environment variables (RADAR_CONTEXT_SWITCH_TIMEOUT,RADAR_FIRST_PAINT_BACKSTOP,RADAR_NAMESPACE_LIST_TIMEOUT,RADAR_MAX_SCOPE_CANDIDATES) — env vars keep secrets out ofpsand let in-cluster deployments source the values from a ConfigMap:

# CLI kubectl radar \ --context-switch-timeout=120s \ --first-paint-backstop=10m \ --namespace-list-timeout=30s \ --max-scope-candidates=200 # Environment (e.g. in a Deployment manifest) RADAR_CONTEXT_SWITCH_TIMEOUT=120s \ RADAR_FIRST_PAINT_BACKSTOP=10m \ RADAR_NAMESPACE_LIST_TIMEOUT=30s \ RADAR_MAX_SCOPE_CANDIDATES=200 \ kubectl radar

Defaults are preserved when neither the flag nor the env var is set, so existing deployments are unaffected.

Interactive graph showing how your Kubernetes resources are connected in real-time.

Topology View — Visualize resource relationships

- Two modes:Resources(full hierarchy) andTraffic(network flow path)
- Group by namespace, app label, or view ungrouped
- Filter by resource kind — click any node for full details
- Auto-layout powered by ELK.js, live updates via SSE

Table-based resource browser with smart columns per resource kind.

Resources View — Browse and filter all cluster resources

- Browse all resource types including CRDs
- Search by name, filter by status or problems (CrashLoopBackOff, ImagePullBackOff, etc.)
- Add custom columns from any label or annotation — sortable, filterable, and resizable
- Click any resource for YAML manifest, related resources, logs, and events

Inspect container image filesystems directly from the Pod view — no need to pull images locally or exec into containers.

Image Filesystem Viewer — Browse container image contents

- Click any container image in a Pod to browse its complete filesystem
- Tree view with file sizes, permissions, and symlink targets
- Search files by name across the entire image
- Download individual files for inspection
- Works with public images (Docker Hub, Quay, GHCR) and private registries (GCR, ECR, ACR) using your cluster's ImagePullSecrets
- Disk-based layer caching for fast repeated access

Unified timeline of Kubernetes events and resource changes.

Timeline View — Track cluster activity in real-time

- Filter by event type (all or warnings only)
- Resource change diffs showing what changed (replicas, images, etc.)
- Real-time updates as new events occur

Helm View — Manage your Helm deployments

- View all releases across namespaces with status, chart version, app version, resource health, storage namespace, and Flux ownership
- Inspect values, compare revisions across values/manifests/notes/resources, and view release history
- Surface failed upgrades, stuck pending operations, rollback history, and inferred atomic-style rollbacks
- Correlate failed/running hooks with remaining Job, Pod, Event, and redacted log evidence
- Upgrade, rollback, or uninstall releases directly from the UI

Diff any two Kubernetes resources of the same kind side-by-side — like comparing a staging Deployment to its production sibling, or two pods that should be identical but aren't.

Compare View — Side-by-side YAML diff with field-level highlighting

- Two entry points: aComparebutton in the resource detail drawer, or compare mode in the resource table (toggle, pick two rows, hit Compare)
- Side-by-side or unifiedview, with one-click swap of A ↔ B
- Diff-only modecollapses unchanged regions so you only see what differs
- Spec-only modedropsstatusfields to focus on intent rather than observed state
- Server-assigned noise (managedFields,resourceVersion,kubectl.kubernetes.io/last-applied-configuration) is stripped automatically so the diff stays signal — flipRaw metadataon if you actually want to see it
- Same-namespace candidates are surfaced first in the picker — usually the resource you want to compare against
- Shareable URLs:/compare?kind=&apiGroup=&a=ns/name&b=ns/name

Compare mode in the resource table — pick two rows, hit Compare

View TLS certificate details and expiry dates across all namespaces — catch expiring certificates before they cause outages.

- Parses TLS secrets to show certificate subject, issuer, and validity period
- Dashboard-level certificate expiry overview
- Available from the resource detail view for any TLS-type Secret

Monitor, diagnose, and manage FluxCD and ArgoCD resources from a dedicated GitOps workspace.

GitOps fleet view — Argo + Flux applications side-by-side with sync, health, source, destination, and lifecycle state

- Fleet view + per-app detail page (Topology / Changes / Activity tabs) forArgoCD(Application,ApplicationSet,AppProject) andFluxCD(GitRepository,OCIRepository,HelmRepository,Bucket,Kustomization,HelmRelease,Alert)
- Diagnosis pipeline— field-level drift, recent events per resource, stuck-drift-loop detection, parsed operation-failures, structured one-click remediation
- Lifecycle awareness—Terminatingchip replaces stale Sync/Health badges; severity ramps with deletion age; mutating ops refuse on zombies
- Cross-linked from the rest of Radar—Managed bychip in resource drawers, GitOps routing from Topology + Timeline + Helm view,Consumed bypanel on Flux source CRs
- MCP integration—manage_gitopsexposes sync / suspend / resume / reconcile / rollback with lifecycle-aware refusal

Visualize live network traffic between services using Hubble, Caretta, Istio, or Beyla.

Traffic View — See how services communicate in real-time

- Auto-detects Hubble (Cilium), Istio, Caretta, or Grafana Beyla as traffic data sources
- Beyla (standalone or via Grafana Alloy) provides eBPF L4 + HTTP visibility with no service mesh, read from Prometheus
- Beyla needs itsnetworkfeature enabled, and per-port edges additionally needdst.portandtransportnamed inattributes.select— both are off by default, and Radar says so in the Traffic view rather than showing partial edges silently
- Animated flow graph showing requests per second between services
- Filter by namespace, protocol, or status code
- Setup wizard to install a traffic source if none is detected

Read-only diagnosis for Karpenter-managed fleets — why is my pod pending, which NodePool could take it, why aren't my nodes joining, what is disruption doing to my fleet? Appears automatically when Karpenter NodePools are detected (RBAC-gated).

- Overview— fleet KPIs with claim lifecycle detail, a cluster scheduling-capacity bar (requests vs allocatable, in-flight beyond the edge, pending demand as an honest not-to-scale count), prioritized operational signals, and the NodePool inventory
- NodePool detail— the capacity ledger (configured limit, provisioned, headroom, allocatable, scheduled requests, unallocated, actual usage), claim lifecycle, fleet composition, and workload attribution
- Demand— pending pods grouped by scheduling signature, each group evaluated against every NodePool's declared constraints with per-predicate evidence; filterable by state, pool, and workload
- Activity— provisioning / disruption / interruption episodes classified from Karpenter's exact event vocabulary, with per-evidence confidence
- Every quantity carries per-value certainty (= ≥ ≤ ?) — unavailable is never rendered as zero, partial is never rendered as exact
- Issues, Pending-pod drawers, and the Home posture card deep-link into the right diagnosis

Track Kubernetes spending with OpenCost integration — no additional configuration needed.

- Cluster hourly and projected monthly cost, top namespaces by spend
- Cost trend charts with 6h/24h/7d range selector
- Namespace and workload-level cost breakdowns with efficiency scoring
- Node costs with instance type and region pricing
- Appears automatically when OpenCost metrics are detected in Prometheus

Proactive best-practices scanner with 31 checks across security, reliability, and efficiency — inspired by Polaris, Kubescape, Trivy, and NSA/CISA guidelines. Runs instantly against cached data with zero cluster-side installation.

- Security: privileged containers, privilege escalation, dangerous/insecure capabilities, host namespaces, container runtime socket mounts, sensitive host paths, secrets in ConfigMaps, auto-mounted service account tokens
- Reliability: missing probes, image taglatest, single-replica deployments, missing PDB/topology spread, pod HA risk (all replicas on same node), orphan services/ingresses, deprecated API versions
- Efficiency: missing CPU/memory requests and limits, orphan ConfigMaps/Secrets
- Check-grouped remediation queue with search and category, severity, and framework filters; expand a check to see affected resources
- Each finding includes description and remediation guidance, with inline hide actions for a check or category
- Configurable: ignored namespaces (with wildcard patterns), disabled checks, persisted across sessions
- Framework labels: NSA/CISA, CIS benchmarks
- MCP tool (get_cluster_audit) for AI-assisted cluster analysis

Hop-ordered diagnosis for Service, Ingress, HTTPRoute, GRPCRoute, and Gateway - answering "if traffic is sent toward this resource, does it reach a healthy process, and if not which hop breaks first?"

OpenChecks → Upgrade impactbefore upgrading the control plane. Radar compares the current cluster with a target Kubernetes minor and orders evidenced compatibility, health, admission, drain, runtime, and configuration checks by required action. Release-specific checks appear only when their Kubernetes minor lies in the selected upgrade path; the current catalog contains 18 checks through Kubernetes 1.36.

- Finds blockers such as skipped minor versions, APIs removed in the target release, unsupported kubelet or kube-proxy skew, overlapping PodDisruptionBudgets, and thegitRepovolume driver disabled in Kubernetes 1.36
- Flags likely operational impact such as FlexVolume exposure and renamed control-plane metrics as warnings, while intent-dependent configuration such as deprecated ServiceexternalIPsremains review
- Inspects live resources, aggregated API availability, Helm release manifests, kubectl last-applied configuration, API server usage metrics, and PrometheusRule expressions
- DistinguishesPassed,Review,Warning,Blocked,Incomplete, andNot applicableinstead of flattening advisory findings, likely impact, and missing evidence into one state
- Scans every namespace the current identity can read; the header namespace picker remains a browsing filter and does not narrow upgrade analysis
- Shows the bundled catalog boundary and the evidence scope for sampled or unavailable data

Inspect what any ServiceAccount can actually do — without threekubectl describecalls.

- ServiceAccount detail: direct bindings, effective permissions (per-binding and deduplicated flat view), inherited grants via implicit groups (system:authenticated,system:serviceaccounts), and "Used by Pods" closing the loop
- Pod detail: "Permissions" section showing the most-permissive rules the Pod's SA grants, plus a blast-radius alert when the SA has wildcards, cluster-admin, escalation verbs, or cluster-widecreate pods
- Workload detail(Deployment / StatefulSet / DaemonSet): same Permissions section framed at the workload level — every Pod the workload spawns inherits these grants
- Namespace detail: RBAC summary with RoleBindings configured here + ClusterRoleBindings whose subjects reference this namespace
- Role / ClusterRole detail: who is bound to this role, with subject summaries inline
- RoleBinding detail: inline preview of the rules the binding grants + warnings when subjects include wide groups (system:authenticated,system:unauthenticated,system:masters)
- "My Permissions" panel: namespace-scoped liveSelfSubjectRulesReviewfor the current user — for fast "why can't I do X" debugging
- MCP:get_subject_permissionstool exposes the same data to AI agents for "is this SA over-privileged?" / "blast radius if compromised?" queries