Skip to main content
Diagnose runs an AI investigation on a Kubernetes resource: root cause, the evidence behind it, and remediation. It comes in two forms that share the same investigation UI:
  • Local (open source) - Radar drives the agent CLI you already have - Claude Code, Codex, or Cursor - against a read-only tool mount, on your machine, under your existing subscription. No API key, no account.
  • Hosted (Radar Cloud) - the investigation runs in Radar Cloud with a Radar-managed agent. Nothing to install, no key to bring; see Diagnose in Radar Cloud.
For the walkthrough of a real investigation, see the product page. For the security reasoning behind the design, see Read-Only Is Not a Safety Boundary.

​
Requirements (local)

  • Standalone Radar (local, no-auth mode) - the BYO-agent form is not available when Radar runs with authentication enabled; in Radar Cloud you get the hosted form instead
  • A supported agent CLI on your PATH: Claude Code (claude), Codex (codex), or Cursor (cursor-agent). Radar detects installed CLIs automatically; if none is present, the feature stays out of your way

​
Starting an investigation

From the UI:
  • The Diagnose button on a resource’s detail header - prominent when the resource has a problem, a quiet icon when it’s healthy
  • Per-row on the Issues queue
  • The top-bar entry, which also shows a live count of running investigations
From the terminal:
The CLI starts the same durable server-side run the panel uses and prints a watch URL, so you can follow the transcript in the browser or stay in the terminal. Before your first run, a consent card explains where data goes (see Privacy). Consent is per machine and shared between the panel and the CLI.

​
During a run

The investigation streams live: the agent’s plan, each tool call with its timing, and a stall hint when the model is thinking. Runs are owned by the server, not the browser tab - close the panel, navigate away, or refresh and the run keeps going. Up to three investigations run concurrently. The tool surface the agent drives is read-only by construction: write tools are not present on the mount, and a regression test fails the build if one leaks in. The agent’s built-in web search is disabled during a run, so what it reads stays between your machine and your model provider.

​
Verdicts

An investigation ends in one of three states:
  • Root cause - what broke, the evidence, and remediation options. The recommended step carries a one-line reason why it’s the safe pick, and confidence is a coarse band (low / medium / high) rather than a percentage
  • All-clear - the agent verified the resource is healthy, not merely found nothing; absence of evidence is not treated as health
  • Inconclusive - RBAC-denied reads, missing data, or genuinely ambiguous state, stated plainly instead of dressed up as an answer
An Explain simply chip rephrases the verdict in plain language, a follow-up composer continues the conversation, and a hand-off action copies the command to resume the session in your own agent CLI.

​
Applying a fix

Apply is deliberately separate from investigating:
  • The confirmation dialog shows the exact change that will run and states that the agent will modify your cluster using your kubeconfig credentials
  • An approved fix runs in a fresh write-enabled session bound to that one confirmed change - content the agent read during the investigation cannot steer what gets written. Apply without a confirmed fix is rejected
  • Changes to GitOps- or Helm-managed resources require an extra acknowledgment: a direct change is reverted on the next sync, so the durable fix belongs in the Git source
  • After an apply, Radar re-checks the resource’s health rather than declaring success

​
Agents and isolation

Pick the agent, model, and reasoning effort under Settings → AI Diagnosis. Nothing about an investigation touches Radar’s servers - runs execute on your machine, and Radar has no key, account, or telemetry in the loop. What the agent reads does go to your model provider (Anthropic, OpenAI, or Cursor’s backend) under your own account; the consent card states this before the first run instead of burying it. Consent is acknowledged per machine, enforced server-side, and re-requested if the disclosure ever changes.

​
History (local)

Runs persist to ~/.radar/ai-runs.db (SQLite, file mode 0600) so transcripts and verdicts survive restarts - retention is 100 runs or 30 days, whichever comes first. Runs interrupted by a restart are marked as errored rather than resumed silently; Cursor sessions cannot be resumed across restarts. Disable persistence with --ai-history=false, and clear it any time from Settings → AI Diagnosis → Clear history.

​
Diagnose in Radar Cloud

In Radar Cloud, Diagnose runs hosted: open a cluster and start an investigation from the same UI - no agent CLI, no API key, nothing installed in your browser or on your machine. The agent appears as Radar Hub (cloud) in the agent picker, and its consent card describes the hosted data flow before the first run. How the hosted form differs from local:
  • Where it runs - each investigation turn runs as a sandboxed, single-purpose job inside Radar Cloud’s infrastructure, using a Radar-managed model. Your cluster is read over the same tunnel your dashboard already uses
  • Read-only, enforced outside the agent - the job reaches your cluster through a short-lived, org- and cluster-scoped, read-only credential held by a separate gatekeeper process; the agent container itself holds no credentials, and write tools are refused fail-closed at that gate
  • No Apply - hosted investigations never write to your cluster. The verdict gives you the remediation; you run it through your normal change process
  • Transcripts persist in Radar Cloud - runs are durable and multi-turn: follow-ups resume the same investigation, and history survives restarts and browser sessions
The privacy trade differs from local mode and is worth stating plainly: locally, cluster reads go to your model provider under your account; hosted, they are processed by a model managed by Radar Cloud - the same trust boundary as the rest of your Radar Cloud dashboard, which already serves your cluster data through the hub.

​
On a self-hosted Hub

The hosted engine is built self-hosted-aware: it is strictly opt-in (disabled unless explicitly configured), and on a self-hosted Hub it uses your own AWS Bedrock account - currently the only supported model provider. You choose the region and the model, the broker forwards invocations of only that model, and the Hub refuses to boot with the feature enabled but region or model unset rather than defaulting to infrastructure your cluster data shouldn’t reach. Investigations then stay entirely within your boundary: your Hub, your cluster tunnel, your Bedrock account. The environment contract - HUB_DIAGNOSE_JOB_IMAGE, the Bedrock region/model/key, and the Job-side DSN Secret - is documented in Self-hosted configuration. Note the chart does not expose these settings yet and the sandbox image is not yet publicly published, so hosted Diagnose is not turnkey on self-hosted installs today; until then, the local BYO-agent form works against any cluster you have a kubeconfig for.

​
Troubleshooting

  • No Diagnose button (local) - Radar is running with auth enabled (the BYO form is standalone-only), or no supported agent CLI was found on PATH
  • Agent CLI errors - failures from the underlying CLI (login expired, version too old) surface in the panel with the action to take
  • 403 when starting a run - the consent card for the resolved agent hasn’t been acknowledged on this machine yet