Radar

Radar is an open-source Kubernetes UI and MCP server, and AI investigations are one surface of it. It lets the AI agent you already use work out why something in your Kubernetes cluster is broken, returning the root cause, the evidence behind it and a proposed fix. Radar's own summary of the flow is direct: click Investigate on an issue and the agent digs into it read-only, then shows you the evidence for what it found. The same investigation can run three ways — from your own agent over MCP, from Radar's UI using your agent CLI, or automatically from Radar Cloud when an alert fires. It is built for people who run Kubernetes and already have an agent such as Claude Code, Codex, Cursor, GitHub Copilot, OpenCode or Google Antigravity, and its stated purpose is to give that agent cluster context rather than replace it with a dedicated AI SRE tool. The stated premise is "You don't need an AI SRE. Give your agent Radar." Your agent knows Kubernetes; what it does not know is your cluster. Radar's FAQ repeats the point: an investigation is only as good as the cluster context the agent reads, and you likely already have the agent. To reason about an incident, that agent needs ranked failures, a change timeline, and logs and owners in one view. Radar also frames its speed advantage around this: an investigation starts from a cluster model that is already joined, time-indexed and checked for failures, so the agent does not begin by assembling the picture itself. The product therefore positions itself less as another AI SRE product and more as the context layer that makes an existing agent effective at Kubernetes incidents. Investigations start from Radar's Issues list, which ranks what is broken across the cluster and places an Investigate button on every issue. There is no prompt to write and no context to paste. Radar's Issues engine ranks failures before anyone asks; in Radar's benchmark it was the agent's first call on all 50 faults. Past runs stay under Investigations, each with its own link, and the UI runs them read-only because write tools are not loaded. The wider Issues feature set that the investigation flow sits on top of groups failures by subject, folds them to the cause and includes blast radius. The result is that a responder does not have to decide where to start: the ranked list of failures is already there, with an entry point to an investigation attached to each one. An investigation answer arrives with its evidence: the log lines, events, metric charts and resources the agent relied on, drawn by Radar from what it recorded. Every claim can be checked, and one click opens the real object behind it. Radar also states how sure the finding is, using three levels — Established, Likely or Still open — so the reader knows whether the cause is confirmed or still being chased. A follow-up question continues the same investigation from where it stopped rather than starting over. When the agent proposes a fix, you approve it, and Radar checks whether it worked. The evidence framing shows in the interface: Radar illustrates an assessment that a Deployment targets a Karpenter node pool that no longer exists, alongside what is still open and an evidence card tagged Cause. Radar's third step is showing the cluster around the answer. Where a chat gives you the answer one line at a time, Radar shows what changed and when, the topology around the workload, its logs and its Helm history, so you can check the agent's story yourself. Spec changes, events and problems sit on one timeline — Radar's Timeline shows an hour of changes, Kubernetes events and problems for each workload on one time axis — and topology, logs, Helm and GitOps live in the same app. Change tracking matters because "what changed before this broke" is one call when spec changes and events are already time-indexed. The same binary also includes an Applications view that folds workloads into the apps they form with health rollups and env skew, GitOps support for Argo CD and Flux with fleet and per-app diagnosis including field-level drift, controller attribution and lifecycle awareness, and a live topology graph of every resource and connection, laid out by ELK.js and updated via SSE. Radar offers three ways to run an investigation. Open source, your agent over MCP: you ask Claude Code, Codex, Cursor, Copilot or any MCP agent from your terminal or IDE, and Radar's MCP server returns the resources with their relationships and recent changes. Open source, your agent CLI run from Radar: click Investigate on anything broken and Radar runs Claude Code, Codex, Cursor or OpenCode read-only on your machine and lays out the findings, the evidence and a fix you approve; Radar detects the agents on your PATH. Radar Cloud: its own agent runs automatically when a rule matches an issue on any connected cluster, or on demand, investigating read-only against the same cluster model and sending the root cause with the alert, evidence included, to Slack or your webhook, with a link to the full investigation and nothing to install on anyone's laptop. A benchmark run shows the MCP route in action — issues, get_changes, get_resource, get_workload_logs and diagnose calls — ending with frontend having lost CART_ADDR at 22:15:29. Safety limits are described explicitly. In Radar's UI and Radar Cloud, investigations are read-only and write tools are not loaded. Over MCP, your agent's write access is your choice, within your RBAC. An approved fix runs alone, in its own session, bound to that one change. Changes to resources managed by Argo CD, Flux or Helm ask for your OK first, because the next sync or Helm upgrade would revert them. With Radar OSS, investigations run on your machine and your own model account. On data: with open-source Radar, what the agent reads goes to your own model provider and never to Radar; in Radar Cloud each investigation runs as a sandboxed job with read-only access, and an owner accepts that once for the organization. Radar explains the reasoning in a post titled "Read-Only Is Not a Safety Boundary", describing why the limits live in the tool layer. The headline outcome Radar reports is speed and cost: 1.6–3.6× faster and 30–85% cheaper than the AI SRE tools tested, on live faults. In its benchmark of 50 live Kubernetes faults across six AI SRE products, Claude Code on Radar's tools was the most accurate of the six — clearly ahead of HolmesGPT, OpenSRE, kagent and AWS DevOps Agent, and slightly ahead of kubectl-ai — answering in an average of 79 seconds at $0.27 a fault, the fastest and cheapest of the six. On faults that announce themselves, such as a crash loop or a failed image pull, all six scored between 24 and 27 of 28; they separate on the 14 faults where every pod reports Ready, where Radar scored 12 against kubectl-ai's 9, HolmesGPT's 7, OpenSRE's 6, kagent's 7 and AWS DevOps Agent's 5. A demonstration run notes kubectl took 11.7 minutes by comparison, and every result is downloadable from the benchmark page. Concrete scenarios appear throughout the content. One is a Deployment whose pods cannot be scheduled because they target a Karpenter node pool that no longer exists; the investigation shows the agent's tool calls, an established assessment, the Deployment as the cause and next steps. Another is a frontend that lost the CART_ADDR environment variable (previously cart:8080) at 22:15:29, so checkout could not reach the cart service even though the cart service itself was healthy. A Timeline example walks a crash loop: a Deployment revision at 10:02, a ConfigMap losing DB_URL at 10:04, and a Pod entering CrashLoopBackOff at 10:05, with the detector connecting the symptom to its likely cause. Alert-driven teams use Radar Cloud, where a rule matches an issue on a connected cluster, the agent investigates read-only against the same cluster model, and the root cause arrives in Slack or a webhook with evidence and a link to the full investigation. Radar is aimed at Kubernetes operators, platform and SRE teams, and developers who already work with a coding agent. Supported agents over MCP include Claude Code, Codex, Cursor, GitHub Copilot, OpenCode and Google Antigravity; from Radar's UI, Claude Code, Codex, Cursor and OpenCode are detected on your PATH; Radar Cloud brings its own agent. Radar is one open-source binary, run on your laptop or in your cluster, installed with a curl script and kubectl radar, Homebrew, the desktop app, in-cluster, Krew, Scoop, .rpm or a direct download. It is Apache 2.0 licensed, requires no account for local use, and can be run as OSS forever. Radar Cloud is the hosted option, offered to try free for three clusters, with pricing on Radar's pricing page. The takeaway Radar reinforces is that you do not need to buy a dedicated AI SRE tool: you need to give the agent you already use the context of your cluster. Ranked issues, a change timeline, joined resources with owners, topology and error-filtered logs, and evidence attached to every claim turn an agent into a Kubernetes investigator that runs read-only, shows its work and proposes a fix you approve — from your terminal, from Radar's UI, or automatically from Radar Cloud when an alert fires.