Radar
Open-source Kubernetes UI and MCP server
919 followers
Open-source Kubernetes UI and MCP server
919 followers
Radar is an open-source Kubernetes UI and MCP server. It shows topology, resources, events, Helm, GitOps, live traffic and security checks, and it gives AI agents the same view: click Investigate on any issue and your agent finds the root cause. Run it locally as a single binary or in-cluster with RBAC and OIDC, no account needed. Radar Cloud adds fleets, alerts and hosted investigations.
This is the 2nd launch from Radar. View more
Radar
Launching today
Your agent knows Kubernetes. It doesn't know your cluster. Radar (open-source) gives it context over MCP: ranked issues, a change timeline, logs and owners in one view. New: click Investigate on a failing workload. Claude Code, Codex or Cursor finds the root cause, read-only, with evidence for each claim. In our benchmark of 50 live faults across six tools, Radar found the most root causes. Radar Cloud investigates every alert and posts findings to Slack.
Free Options
Launch Team / Built With
Framer AI AgentsDesign and publish professional sites with AI
Promoted
does the redaction also apply to logs pulled through /mcp-readonly, not just when Investigate runs
@bbueno yes - investigate basically just calls the MCP endpoint. It's a relatively basic script around it that triggers your own agent CLI with params, query and the MCP setup - not heavy business logic
The change timeline is the part I'd look at first. Seeing what changed just before a workload failed gives the investigation somewhere to start.
@oleksii_sekundant thanks - one of the key differentiators from tools that don't use it well enough
Fresh news: Radar is now #1 on SREGym benchmark: https://sregym.com
And it's not even close 😅
The read-only-until-approved default is the right way to let an agent near a cluster. On the 50-fault benchmark, did the six misses cluster around one failure type, or were they just noise?
@christian__schneider not noise - but not exactly one specific type. it was generaly things that are very hard to observe from k8s objects alone, and need some deeper inspection of the workload. e.g. read something broken with the DB auth, or some env var that changed when loaded via file, when there's not even a failing workload per se. Things that are really not "oh this pod has crashloopbackoff". You can see more details in radarhq.io/benchmark and the source for these scenarios in sregym.com