AI investigations for your Kubernetes cluster. Your own agent, keyless.
Point Diagnose at a misbehaving resource and the agent CLI you already have - Claude Code, Codex, or Cursor - investigates it against Radar's live cluster model: root cause, the evidence behind it, and a fix you approve before anything changes. No API key, no account, nothing sent to Radar.
A real investigation, not a mock - captured end-to-end in the walkthrough below.
One investigation, start to finish.
A Deployment crashing on a renamed ConfigMap key, investigated by Claude Code through Radar - captured from a real run, unretouched. Click through the four moments that matter.
Radar already knows what's broken
Both checkout-worker pods are stuck in CreateContainerConfigError. The deterministic Issues engine has already classified the failure - down to the missing ConfigMap key - and the row carries a Diagnose button. That's the whole setup: one click.
Your own agent, working read-only
Radar drives the agent CLI you already have - here, Claude Code - against a read-only tool mount. You watch the investigation live: the plan, each tool call with its timing, and an honest stall hint when the model is thinking. No API key, no account, nothing sent to Radar.
Root cause, argued - not asserted
The verdict pins to its own rail: what broke, the evidence, and remediation options with the recommended one argued - why it's the safe pick, as a coarse confidence band instead of a fake percentage. If the agent can't tell, it says inconclusive instead of inventing a story.
Nothing changes until you say so
Apply shows the exact command it will run and says plainly that it changes your cluster - then runs in a separate write session bound to that one confirmed fix, so nothing read during the investigation can steer what gets written. Afterward Radar re-checks health instead of declaring success.
AI troubleshooting usually starts with a paste.
The way most teams use AI on a broken cluster today is copy-paste: a pod description into a chat window, then the events, then the logs, one round-trip at a time, with you as the transport layer. The tools that fix that mostly introduce two new problems - another API key to provision, and another vendor's judgment about how much cluster access is safe to give a model.
Diagnose takes a different deal. You already pay for an agent. Radar hands it structured, scrubbed, read-only access to the live cluster model it already maintains, runs the investigation on your machine, and gives you back a verdict built to be checked. Radar never sees a byte of it.
Three verdicts. All of them honest.
Root cause, argued
Evidence, remediation, and why the recommended fix is the safe pick - confidence as a coarse band, not a fake percentage.
All-clear means verified
Absence of evidence is not health. A green verdict means the agent checked, not that it found nothing.
Inconclusive is an answer
RBAC-denied, missing data, ambiguous state - said plainly instead of dressed up as a diagnosis.
The boundaries live in the tool layer, not the prompt.
You can't instruct a model into safety. Every guarantee below is enforced where a prompt injection can't negotiate with it - and where one can't be, Radar says so out loud.
Read-only by construction
Write tools aren't present on the investigation surface - not disabled, absent - and a regression test fails the build if one leaks in.
Apply is a separate session
An approved fix runs in a fresh session bound to that one confirmed change, so injected reads can't steer writes.
Exits cut during runs
Built-in web search is off during a run. Where a CLI can't be fully closed (Cursor), Radar says so in a consent step.
Your keys stay yours
No API key to Radar, no account. The agent runs under your existing subscription, and the consent card says where data goes.
GitOps-aware applies
Direct changes to Argo-, Flux-, or Helm-managed resources gate behind an explicit acknowledgment - they'd revert on the next sync.
Local, on your machine
Ships in standalone OSS Radar, runs against your kubeconfig, loopback-checked. Nothing touches Radar's servers.
The full reasoning behind these boundaries is in our post Read-Only Is Not a Safety Boundary -
and all of it is code you can read, not policy you have to trust.
AI on top of a deterministic layer - not instead of one.
Diagnose doesn't reason over raw YAML floods. It starts from the same structured layers the rest of Radar is built on: the deterministic Issues engine that already classified what's broken, and the MCP tool surface that hands agents topology, correlated timelines, and scrubbed logs. Our 52-scenario benchmark measured that tool surface, not Diagnose itself - and it's why Diagnose is built on it: an agent on the structured tools out-diagnosed the same agent on raw kubectl (80.8% vs 77.6% pass rate) with 76% fewer tool calls.
The health signal the investigation starts from is computed, not asserted by the model - so the agent confirms or refutes a real diagnosis instead of being told something is broken and manufacturing a story to match. Rules where rules win, a model where judgment helps, and a clear line between them.
Apache 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.
Questions we get about Diagnose.
Do I need an API key or a Radar account?
Where does my cluster data go?
Can Diagnose change my cluster?
What happens when it can't figure out the cause?
Which agent CLIs are supported, and how isolated are they?
Is this the same engine as the Issues queue?
More of what Radar does in the same binary.
Your agent already knows Kubernetes. Give it the cluster.
Install Radar, click Diagnose on the thing that's broken, and watch your own agent argue the root cause.
Apache 2.0 · Self-host forever · Cloud for fleet, alerts, SSO