Radar

Radar is an open-source Kubernetes UI and MCP server that lets the AI agent a team already uses investigate broken workloads. From Radar, a user clicks Investigate on an issue, and Radar runs Claude Code, Codex, Cursor or OpenCode read-only on the user's machine; it then lays out the findings, the evidence and a fix the user can approve. The same investigation can be started from an MCP client, and Radar Cloud runs the same setup when an alert fires. Its main purpose is to give an existing agent the cluster context it needs to find the root cause of a Kubernetes failure. The result is a root cause view that combines an agent's reasoning with cluster data the user can inspect. The product addresses a specific gap: an agent knows Kubernetes, but it does not know your cluster. A generic chat can return an answer one line at a time without showing the changes, topology, logs and ownership relationships behind it. Radar is built to supply that context before and during an investigation, so the agent starts from a cluster model that is already joined, time-indexed and checked for failures. This matters because an investigation is only as good as the cluster context the agent reads, and Radar aims to make that context available without asking a user to paste prompts or assemble evidence manually. Radar's Issues list ranks what is broken across the cluster, and an Investigate button sits on every issue. There is no prompt to write and no context to paste. Past runs stay under Investigations, each with its own link, and the UI investigations are read-only because write tools are not loaded. After an investigation, the answer arrives with its evidence: the log lines, events, metric charts and resources the agent relied on, drawn by Radar from what it recorded. One click opens the real object, and Radar states how sure the finding is as Established, Likely or Still open. A follow-up question continues the same investigation from where it stopped, and an approved fix is checked to see whether it worked. This arrangement keeps the history of an investigation attached to the issue it concerns and makes the result easy to share or revisit. The open-source path lets an agent work over MCP. Claude Code, Codex, Cursor, GitHub Copilot, OpenCode or any MCP client can ask Radar from a terminal or IDE, and Radar's MCP server returns resources with their relationships and recent changes. The second path runs an agent CLI from Radar itself: clicking Investigate on anything broken runs Claude Code, Codex, Cursor or OpenCode read-only on the machine and lays out the findings, evidence and a fix to approve. Radar detects which supported agents are on the PATH. The third path is Radar Cloud, which brings its own agent: it runs automatically when an alert fires or on demand, sends the root cause with the alert, evidence included, to Slack or a webhook, and requires nothing to be installed on anyone's laptop. The speed comes from the cluster model the agent starts with. Radar's Issues engine ranks failures before anyone asks, and in the benchmark it was the agent's first call on all 50 faults. Spec changes and events sit on a timeline, so the question of what changed before something broke is one call. Resources come back joined: owners, topology and error-filtered logs are correlated and secret-redacted in one response, so the agent begins with connections already made. Radar keeps, for every cluster, the resources joined into a graph, every change on a timeline and detectors that connect a symptom to its likely cause. The topology graph lays out every resource and connection using ELK.js and updates via SSE, and the same app includes Helm and GitOps context for checking an answer. Because those pieces are already assembled, the agent does not spend its early calls reconstructing ownership or collecting logs; it can move into diagnosis. Radar also adds guardrails around investigations. In Radar's UI and Radar Cloud, investigations are read-only: write tools are not loaded. Over MCP, the agent's write access is the user's choice within their RBAC. An approved fix runs alone in its own session, and changes to resources managed by Argo CD, Flux or Helm ask for explicit acknowledgment because the next sync or Helm upgrade would revert them. This separation keeps an investigation from turning into an uncontrolled change to the cluster, and it gives the user a clear point to review before anything is applied. With Radar OSS, investigations run on the user's machine and use the user's own model account; what the agent reads goes to the user's model provider, not 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. The product is backed by benchmarks on live faults. In a benchmark of 50 live Kubernetes faults across six AI SRE tools, 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. It answered in an average of 79 seconds at $0.27 a fault, the fastest and cheapest of the six, and Radar was 1.6–3.6× faster and 30–85% cheaper than the AI SRE tools tested. On faults that announce themselves, all six products scored between 24 and 27 of 28; on the 14 faults where every pod reports Ready, Radar scored 12. These results support the claim that an existing agent with Radar's context can outperform dedicated AI SRE tools. The benchmark page provides downloadable results, and Radar links to separate benchmarks for Kubernetes MCP servers and MCP versus kubectl. Concrete workflows follow from these capabilities. A user can investigate a Pod in CrashLoopBackOff and see that a ConfigMap lost DB_URL a minute before the crash loop. For a Deployment whose pods cannot be scheduled, the agent can check resources and changes, establish that the pods target a Karpenter node pool that no longer exists, and show the Deployment as the cause with next steps. When an alert fires, Radar Cloud investigates it and posts the finding to Slack or a webhook. Developers can also run investigations from Claude Code, Codex, Cursor or another MCP client in the terminal or IDE, then review the timeline, topology, logs, Helm history and GitOps state to verify the agent's story. Evidence cards are tagged and linked to the objects they describe, so the user can move from a claim to the underlying resource. Radar is distributed as an open-source, single binary under Apache 2.0 with no account for local use, and it can be run on a laptop or in a cluster. Installation options include Homebrew, a desktop app, in-cluster use, Krew, Scoop, .rpm and direct download. The quick install command shown is curl -fsSL https://get.radarhq.io | sh && kubectl radar. Radar Cloud is available free for three clusters, and its pricing page is linked for further plans. The product connects to agents including Claude Code, Codex, Cursor, GitHub Copilot, OpenCode and Google Antigravity over MCP; from Radar's UI it supports Claude Code, Codex, Cursor and OpenCode, while Radar Cloud brings its own agent. The same binary also includes Issues and root cause, Applications view, GitOps for Argo and Flux, and a live topology graph. Radar's primary value is that it turns an existing AI agent into a Kubernetes investigator by giving it a prepared cluster model, evidence and read-only safety instead of asking teams to buy a separate AI SRE. It supports investigation from an MCP client, from Radar's UI with a local agent CLI, or automatically through Radar Cloud, and it keeps the cluster context around the answer so users can check the root cause themselves.