peterindia.netopen-source SRE agents
Six open-source projects that shorten the first, confusing minutes of an incident. Each plugs into the monitoring you already run, which is what makes them practical. Here is where each fits in the incident workflow.
Typical order of use during an incident, from telemetry to agent-building.
Scans a Kubernetes cluster and explains what is broken in plain English. Pluggable analysers find failing pods, services and nodes, and any LLM backend can write the explanation.
When to pick it: Best first step if you want a quick read on a sick cluster.
Given an alert, it pulls logs, metrics and Kubernetes state and works backwards to the probable root cause. A CNCF Sandbox project; repo moved from robusta-dev to the HolmesGPT organisation.
When to pick it: Pick it when the question is why an alert fired, not just what is broken.
Open-source AIOps and alert-management platform that pulls alerts from 100+ tools, deduplicates and correlates them so you can tell signal from noise. Keep has announced it is joining Elastic.
When to pick it: Use it to cut alert fatigue before any agent starts investigating.
Adds context to Prometheus alerts for Kubernetes: smart grouping, AI enrichment, linked runbooks and automatic remediation steps, delivered to Slack and similar tools.
When to pick it: Good fit when you already run Prometheus and Alertmanager.
A Kubernetes-native framework for building and running AI agents inside your clusters, with tool servers, any-LLM support and governance. A CNCF Sandbox project built by the founders of Istio.
When to pick it: Choose it to build your own SRE agents rather than adopt a ready-made one.
OpenTelemetry-native observability platform for logs, metrics and traces, with an MCP server so AI agents can query it. The source post lists it as supporting infrastructure, not an agent.
When to pick it: Gives every agent above reliable telemetry to reason over.
Licences and project status as listed on GitHub in October 2026.
| Project | Type | Stage | License | CNCF |
|---|---|---|---|---|
| K8sGPT | CLI + operator | Diagnose | Apache-2.0 | — |
| HolmesGPT | Investigation agent | Investigate | Apache-2.0 | CNCF Sandbox |
| Keep | Alert platform | Correlate | Open core (check repo LICENSE) | — |
| Robusta | Alert enrichment | Enrich | MIT | — |
| kagent | Agent framework | Build & run | Apache-2.0 | CNCF Sandbox |
| SigNoz | Observability platform | Observe | Open core (check repo LICENSE) | — |
Before you install anything.
It is software you can run and inspect yourself that uses an LLM to help with operations work, such as explaining a failing cluster, investigating an alert or correlating noisy alerts. Unlike hosted products, you control the code, the data it sees and the model behind it.
The source post's advice is to favour tools that plug into the monitoring you already have. If you run Prometheus, start with Robusta; if you want a quick cluster diagnosis, K8sGPT; if you want root-cause investigation on alerts, HolmesGPT.
No. SigNoz is an OpenTelemetry-native observability platform. It is on the list because agents need good telemetry and SigNoz exposes it, including through an MCP server.
Treat them as read-only assistants first. Start with diagnosis and enrichment, review every suggested fix, and add approval gates before any automated remediation.
HolmesGPT and kagent are CNCF Sandbox projects. Sandbox is the earliest stage, so expect fast change.
Most of these tools let you bring your own model, including local ones, so cost depends on what you choose. Check each project's docs for supported providers.