Open Source SRE Agents in 2026: 9 Compared, 3 Tested

The strongest open source SRE agents for investigating a live alert in October 2026 are HolmesGPT and Aurora. On the same 19 injected Kubernetes faults, two runs each, Aurora was graded correct in 34 of 38 runs (grades read by a person) and HolmesGPT in 31 of 38 (judge-model grades only), a gap that is not statistically significant, and HolmesGPT was about 3x faster. K8sGPT is a different kind of tool: it scans a cluster and explains what its analyzers flag, rather than investigating an alert. If you want to build your own agent rather than run one, look at OpenSRE, kagent and Mezmo's AURA, which we have not tested.

Arvo builds Aurora and wrote the 19 scenarios. Everything we ran is public in Arvo-AI/aurora-lab, and the live table is at /benchmark.

Which open source SRE agents exist, and which did we test?

Stars, licenses and releases were read from the GitHub API on 2026-10-21. "Tested" means we installed the tool and ran it on all 19 faults. "Repo check" means we read the README, docs and license, and did not run it.

Stars measure attention, not quality. OpenSRE and Keep lead on stars; Aurora has the fewest of the three we tested.

How we evaluated the three we tested

We built a small app (shop: an nginx frontend, a Python api, a worker, redis and a load generator) on a kind v0.33.0 cluster running Kubernetes v1.37.0 with 3 nodes. Each scenario injects one known fault (two in scenario 12) with a break.sh script, and a check.sh proves the fault is visible before any agent starts. Each tool ran twice per scenario: 38 runs per tool, 114 in total.

All three used the same cluster-admin kubeconfig, each behind its own guard: Aurora's command policy, HolmesGPT's command allow-list, and K8sGPT's read-only analyze. What each tool received:

• Aurora (commit 87d22baf, model bedrock/us.anthropic.claude-sonnet-5): the alert text plus "Cluster: aurora-lab (kubeconfig). Investigate and find the root cause." It ran under its default read-only observability_only command policy, with a fresh user and org per run so no memory carried over.
• HolmesGPT 0.43.0 (same model): the alert text plus "Namespace shop, cluster kind-aurora-lab. Find the root cause and say what changed." through holmes ask with default toolsets. The lab has no Alertmanager, so holmes investigate was not used. No HolmesGPT transcript shows a mutating command.
• K8sGPT 0.4.40: no alert, because it has no notion of one. It ran the command below. It used us.anthropic.claude-sonnet-4-5, because K8sGPT sends a temperature parameter that Bedrock rejects for Sonnet 5.

k8sgpt analyze --explain --namespace shop

An answer is correct when it states every required finding for the scenario and asserts none of the listed wrong answers; partial when it states some. A judge model (us.anthropic.claude-opus-5-5) graded every answer against the injected fault. Review is not the same for all three tools:

• Aurora's 38 grades were read and confirmed by a person at Arvo, who changed none.
• HolmesGPT's and K8sGPT's 76 grades are judge-model only. A second model re-read all 76 and agreed. A third pass graded all 76 from scratch: it agreed on all 38 HolmesGPT verdicts and disputed 6 K8sGPT labels. No person has checked these 76 yet.
• A blinded regrade, with agent names, tool names and the cluster name removed, matched the published verdict in 38 of 38 Aurora runs, 37 of 38 HolmesGPT runs and 36 of 38 K8sGPT runs. Every change moved a verdict down.

The prompts differ in wording, as quoted above. HolmesGPT's own command allow-list blocked kubectl rollout history in 12 of its runs, including 2 of its 7 non-correct runs, and we did not rerun those with the command allowed. Aurora's policy had the same block in our first lab report. The judge model comes from the same vendor as every model under test.

Aurora vs HolmesGPT vs K8sGPT: results on 19 Kubernetes faults

On correct against not correct, the two-sided Fisher exact test that /benchmark computes from these totals gives p = 0.52 for Aurora against HolmesGPT (34 of 38 against 31 of 38). It compares Aurora's person-read grades with HolmesGPT's judge-only grades; on the blinded regrade (34 against 30) the same test gives p = 0.35. With 38 runs each and a model judge, read the two as roughly even on accuracy. HolmesGPT is clearly ahead on speed: its median run took 45 seconds against Aurora's 153.5. Aurora's times include contention from its own background jobs in the lab stack, which the lab repo's REPORT.md describes, but that does not close a 3x gap.

Per scenario (correct runs out of 2; for K8sGPT, the judge's labels):

Every row links to its transcripts and grade files on /benchmark.

Where both agents failed

Scenario 12 broke both. The worker is OOMKilled and the alert says so; separately, the frontend Service selects no pods. Both tools found the OOM in both runs and neither reported the frontend outage. Aurora went further and wrote that it did not exist:

Other workloads in the shop namespace (api, frontend) remained healthy and unaffected [5, 14].

Pod status was its only evidence. The runbook a second fault the alert does not cover shows the checks that would have caught it.

Scenario 19 is the other hard one: only the restarted frontend pod loaded an edited ConfigMap. HolmesGPT's first run blamed a cold-start race between frontend and api pods and closed with "All data points to a transient startup race, now resolved." That is its one wrong verdict. Aurora's first run found the edited upstream but did not work out that only the recreated pod had loaded it. It tried to read the live config with kubectl exec, its read-only policy blocked that, and it missed the clue already in its own get pods output: the failing pod was 9 seconds younger than the healthy one. Both got it right on the second run. The runbook is ConfigMap change not applied to all pods.

What K8sGPT does and does not do

K8sGPT answers a different question. It runs analyzers over the objects in a namespace and has the model explain each finding; it takes no alert and does not follow a chain of evidence. Grading it on alert-driven criteria tells you what it misses, not that it failed the same task. In 12 of 38 runs (both runs of 6 scenarios) it printed "No problems detected", including the NetworkPolicy, the slow leak and the config drift, where every object looks healthy to an analyzer. In the other 26 it reported a symptom on a related object; the judge graded 21 partial and 5 wrong. The second model agreed with all of those labels; the third, independent pass would have called 6 of them "no answer", because they restate a symptom and give no cause. When the fault is visible on an object, it is fast and concrete. This is the first finding in its output for scenario 03, run 1, verbatim:

0: Pod shop/frontend-7b6c998456-rv848(Deployment/frontend)
- Error: Back-off pulling image "nginx:1.27-alpne": ErrImagePull: rpc error: code = NotFound desc = failed to pull and unpack image "docker.io/library/nginx:1.27-alpne": failed to resolve reference "docker.io/library/nginx:1.27-alpne": docker.io/library/nginx:1.27-alpne: not found
Error: The Docker image "nginx:1.27-alpne" cannot be found because the tag name is misspelled.

The judge marked it partial because it never said the old ReplicaSet was still serving, and its Service finding implied an outage. K8sGPT's median was 12.5 seconds for two passes, it can anonymize resource names before they reach the model, and its operator now has an opt-in, alpha auto-remediation mode. For a cluster health scan it is the cheapest of the three to run. For "this alert fired, why?" it is the wrong tool. More in HolmesGPT vs K8sGPT.

The open source SRE agents we did not test

These were checked from their repos and docs on 2026-10-21. We did not run them, so nothing below is a statement about how well they investigate. Any of them can be added to the benchmark (see the end of this page).

OpenSRE (Tracer-Cloud)

A framework for building AI SRE agents, and the most starred project here. The README lists 60+ integrations across observability, cloud, databases and incident tools, a tool-calling loop that answers with evidence-linked responses, optional masking of identifiers before external LLM calls, and optional execution of remediation. It is marked public alpha, and the interactive shell requires signing in to an account. Self-hosting is a container with LLM_PROVIDER set. Product telemetry is opt-out. Pick it if you want to assemble your own agent and are comfortable with an alpha API.

kagent

A CNCF Sandbox project (accepted 2025-05-22) for running agents inside Kubernetes. Agents, their prompts, tools and models are custom resources, so they live in Git and deploy through GitOps. It ships an MCP server with tools for Kubernetes, Istio, Helm, Argo, Prometheus, Grafana and Cilium, and stores sessions in PostgreSQL. It is a framework: you write the SRE agent. The latest release is still an alpha of 1.0. This is the closest match for "investigations and remediation workflows versioned alongside application code".

Mezmo AURA

An SRE agent runtime from Mezmo, written in Rust. Models, specialist agent teams, prompts, tools, approval policies and guardrails are all defined in reviewable TOML. Sensitive tool calls can require human approval, and the README says denial, timeout and transport failures are handled fail-closed. It exports OpenTelemetry traces of every model and tool call and connects tools over MCP. Mezmo says it began as its internal harness for operating its own SaaS. If your requirement is multi-agent workflows with explicit approval gates that you own, it is worth a trial.

Keep

An alert management and AIOps platform: one place for alerts from many monitors, with deduplication, correlation, enrichment and workflows. Its AI backends are used for enrichment, correlation and gathering incident context. It does not present itself as an investigation agent; it sits in front of one. See Keep vs Aurora.

Coroot

Open source eBPF observability (metrics, logs, traces, profiles) with predefined inspections that explain many problems without an LLM. Its AI root cause analysis is not in the open source edition: per Coroot's docs, it comes through Coroot Cloud (10 free investigations a month) or Coroot Enterprise. Aurora has a Coroot connector, so the two can be used together.

Versus Incident

A self-hosted incident tool with an agent that learns normal log patterns and opens an incident when a new error appears, with training, shadow and detect modes so you can watch its judgement before it alerts. It routes incidents to Slack, Teams, Telegram and email and to PagerDuty, Opsgenie, incident.io and ServiceNow. Its focus is detection and notification; investigation is an AI triage summary on each incident.

Also found and left out: aptible/unpage is archived; fuzzylabs/sre-agent has had no commits on its default branch since March 2026; microsoft/sre-agent holds material for Azure SRE Agent, which is a hosted Microsoft product, not an open source agent (see our Azure SRE Agent alternative).

Which open source agent fits which team?

What about closed AI SRE platforms like Resolve AI, Datadog Bits AI and Dynatrace Davis?

We have not tested any closed AI SRE product, and none is on the benchmark, so we cannot give you a number. What the open source tools give you that closed ones cannot is inspection: you can read the agent's prompts and tool calls, run it inside your own network, pick and swap the model, and keep its memory in your own database. In Aurora, knowledge-base write-back needs a human thumbs-up, and all of it lives in your deployment. The trade is that you operate it.

Each closed platform has its own page, checked against the vendor's docs:

• Resolve AI: Resolve AI alternatives and Cleric vs Resolve AI
• Datadog Bits AI SRE: Datadog Bits AI alternatives
• Dynatrace Davis AI: Dynatrace Davis AI alternatives
• LogicMonitor Edwin AI: Edwin AI vs Dynatrace Davis AI vs Datadog Bits AI
• Azure SRE Agent: Azure SRE Agent alternative
• New Relic AI and Splunk ITSI: New Relic AI alternative, replacing Splunk ITSI
• Incident platforms with AI features: incident.io, Rootly, PagerDuty
• Prices across all of them: AI SRE and incident tool pricing

For deployment inside your own network, see self-hosted AI SRE.

Can I rerun the test, or add another agent?

Yes. The scenarios, runner, every transcript and every grade are in Arvo-AI/aurora-lab:

git clone https://github.com/Arvo-AI/aurora-lab && cd aurora-lab
./lab.sh up && ./lab.sh break 03-bad-image-tag
./runner/h2h.sh 03-bad-image-tag runs/mine

h2h.sh runs HolmesGPT and K8sGPT on Bedrock, so it needs AWS credentials with Bedrock access (AWS_PROFILE, AWS_REGION).

To add an agent (OpenSRE, kagent and AURA are the obvious next ones), open an issue with the "Benchmark: add an agent" template: a command that takes the alert text and a read-only kubeconfig and prints the root cause. We run it on all 19 faults, grade it with the same judge prompt, have a person check the verdicts and publish the result. To check one failure against your own cluster, /diagnose walks through it. The three-way write-up with more traces is Aurora vs HolmesGPT vs K8sGPT.

What we would change next time

The test is Kubernetes-only, on a synthetic app, with faults we wrote. It says nothing about cloud APIs, logs at scale, or noisy production alerts. HolmesGPT 0.44.0 and 0.45.0 were already out when we ran 0.43.0, and K8sGPT 0.4.41 shipped on 2026-10-21, after our runs, so their current versions are untested. HolmesGPT's grades still need a person to read them, and its cost per run was not captured. We plan to rerun all three every quarter and when any of them ships a major version.

Verified 2026-10-21: repo stars, licenses and releases from the GitHub API; benchmark numbers from results.json generated 2026-10-21; HolmesGPT and K8sGPT runs on 2026-10-15 and 2026-10-16; Aurora runs on 2026-10-02.

Aurora is on GitHub under Apache 2.0, or book a demo to see it on your own alerts.