K8sGPT Alternatives: We Tested K8sGPT on 19 Faults (2026)

The main K8sGPT alternatives are HolmesGPT (an open-source CNCF Sandbox agent that investigates an alert across Kubernetes and other data sources), Aurora (an open-source AI SRE that investigates across clouds and drafts fixes for human approval), kagent (a CNCF Sandbox framework for building your own agents inside Kubernetes), Robusta (Prometheus alert enrichment in Slack) and Komodor's commercial AI SRE. Which one fits depends on why you are leaving K8sGPT. K8sGPT is a scanner: it lists Kubernetes objects that look unhealthy and asks an LLM to explain each one. When we ran K8sGPT 0.4.40 twice on each of 19 injected faults, it quoted the specific error behind the fault in 9, reported only a generic symptom (a container that exited with Error, a pod that was not ready) in 4, and printed "No problems detected" in both runs of the other 6, where no object it checks looked unhealthy.

The rest of this page is the evidence: what k8sgpt analyze --explain printed for each fault, why the 6 misses happened, where K8sGPT did better than the agents, and then the alternative for each reason people move on. Every run folder is public in Arvo-AI/aurora-lab, and the full three-tool table is on the AI SRE benchmark page.

Disclosure: Arvo builds Aurora and wrote the 19 scenarios. Read the Aurora numbers with that in mind.

How we tested K8sGPT

We broke a small synthetic app (shop: nginx frontend, Python api, worker, redis) on a 3-node kind v0.33.0 cluster running Kubernetes v1.37.0, one known fault at a time, and ran K8sGPT twice per fault, on 2026-10-15 and 2026-10-16. The command, from the lab runner:

k8sgpt analyze --explain --namespace shop --no-cache

The runner runs it twice per fault, once with --output json and once as text, so the recorded time covers two analyze passes. K8sGPT used the Amazon Bedrock Converse backend with Claude Sonnet 4.5. We wanted Sonnet 5, the model the other two tools ran on, but K8sGPT always sends a temperature parameter and Bedrock rejects it for Sonnet 5. The analyzer set was the default one: k8sgpt filters list on the machine that ran it, checked again on 2026-10-21, shows NetworkPolicy and Log among the unused filters.

K8sGPT got no alert, because it has no notion of one. HolmesGPT 0.43.0 and Aurora (commit 87d22baf) got the alert text for each fault and were asked to find the root cause. Aurora's 38 runs are older: they ran on 2026-10-02 against the same kind cluster and the same injected faults. K8sGPT and HolmesGPT ran with the cluster admin kubeconfig (HolmesGPT's own command allow-list kept it read-only in practice); Aurora ran under its default read-only observability_only policy.

A judge model (Claude Opus 5.5) graded every answer against the injected fault. For K8sGPT and HolmesGPT those 76 grades are judge-model only: a second model re-read all of them, a third pass graded all 76 from scratch, and a blinded regrade removed tool names. No person has checked them yet. Aurora's 38 grades were read by a person.

K8sGPT is scored here on a criterion built for alert-driven investigators, which is not what it was designed to do. So the table below says what it reported rather than ranking it at 0% correct.

What did K8sGPT find on the 19 faults?

Totals over 38 runs: 21 partial, 5 wrong, 12 "No problems detected", 0 correct. The first model review agreed with all 76 grades. The third pass, which graded from scratch, disputed 6 K8sGPT labels (both runs of 05, 10 and 18) and called them no answer, because the text restates a symptom without a cause. The blinded regrade moved two K8sGPT runs down as well (r1 of 05 to no answer, r1 of 18 to wrong). We kept the judge's labels, which are the more generous reading for K8sGPT.

Run time. The median was 12.5 seconds for the two passes. Runs with findings took 8 to 46 seconds; the 12 clean scans took 0 to 1 second, because there was nothing to send to the model. HolmesGPT's median was 45 seconds for one investigation and Aurora's 153.5 seconds.

Why "partial" and not "correct"

In the 9 faults where K8sGPT quoted the specific error, the error string was right and often exact. What it did not do was say why the object broke or how findings connect. Three examples from the grade files:

• 01, worker OOM. It reported the OOMKill and suggested raising the memory limit (with 2Gi as the example in one run), but never mentioned the BATCH_SIZE change from 500 to 2500 that caused it.
• 09, redis PVC. The output was a flat list of six findings. It never linked the api crash loop to redis being down, which was the point of the scenario.
• 07, selector mismatch. It treated app=api-v2 as correct and suggested relabeling pods instead of reverting the selector. In the same run it flagged an unrelated redis ClusterIP repair event and suggested kubectl delete svc redis -n shop, which is noise at best.

That is the scanner design working as documented. The K8sGPT README describes it as "a tool for scanning your Kubernetes clusters, diagnosing, and triaging issues in simple English", with "SRE experience codified into its analyzers". Each analyzer checks one resource type, and the LLM explains one finding at a time.

Which faults can K8sGPT not see?

In 4 of the 6 misses (11, 13, 15, 19), no object in the namespace was in a failing state that a default analyzer checks. The other 2 (06, 17) are less clear-cut:

• 11, wrong targetPort. The api pods were Running and Ready and the Service had endpoints. Every connection was refused anyway. (runbook)
• 13, NetworkPolicy. Every pod was Running and Ready; only the api to redis path was blocked. The NetworkPolicy analyzer is optional and was off. We did not rerun with it, so we do not know whether it would have flagged this policy. (runbook)
• 15, stray pods sharing a label. The stray pod passed its /healthz readiness check and returned 500 on every other path. With three pods behind the Service, about one request in three failed. (runbook)
• 19, partial config reload. Both frontend pods were Running. One had started with the edited ConfigMap, the other still served the old config from memory. (runbook)
• 06, liveness probe on the wrong port, and 17, slow memory leak. The containers were being killed repeatedly, yet all four scans reported nothing. Between kills the container is up again (in 06 readiness passes between restarts). We did not capture pod state at the moment of each scan, so we cannot say which check skipped it. (liveness runbook, memory leak runbook)

The two alert-driven agents did better on these 6 faults, because they start from the alert (for 15, "31% of requests to /api/ returned 5xx"; for 06 and 17, a crash-loop alert) and follow it to the cause. All 12 runs per tool:

Faults outside the cluster are a harder limit. Every built-in K8sGPT analyzer reads Kubernetes objects; of the optional integrations, the AWS one adds a single EKS check that reads the cluster's own health issues from the EKS API. A saturated managed database or a cloud load balancer only shows up through whatever Kubernetes symptom it causes. Our lab does not include out-of-cluster faults, so we have no measured number for that case.

Where K8sGPT did better than the agents

Scenario 12 had two faults at once, and the alert mentioned only the worker. K8sGPT reported the frontend Service selecting no pods in both runs. Aurora and HolmesGPT missed that second fault in all four of their runs: they explained the worker OOM and never checked Services or endpoints. Both Aurora RCAs went further and stated that the frontend was healthy and unaffected, which was false. A scan that does not care about the alert covers the whole namespace. (runbook)

It is also fast and cheap: a clean scan took about a second and had nothing to send to the model, and the exact strings it pulled (nginx:1.27-alpne: not found, secret "api-secrets" not found, exceeded quota) are what you would want pasted into a ticket.

When is K8sGPT the right tool?

Keep K8sGPT when the job is "tell me what is unhealthy in this cluster right now" rather than "explain this alert". Specifically:

• Continuous posture checks. The k8sgpt-operator re-runs analysis on an interval that defaults to 30 seconds and can send results to a Slack sink.
• Catching faults nobody alerted on, as scenario 12 showed.
• A low footprint and strict data handling. It is a single CLI, a CNCF Sandbox project since 19 December 2023, Apache 2.0, and supports local backends such as Ollama and LocalAI. Its --anonymize option masks object names and labels before they reach the AI backend.
• Giving an assistant cluster tools. k8sgpt serve --mcp starts an MCP server that the README says provides 12 tools for clients like Claude Desktop.

Nothing stops you from running K8sGPT next to an investigator instead of replacing it; scenario 12 is the argument for doing that.

Which K8sGPT alternative fits your reason for leaving?

HolmesGPT

The HolmesGPT README describes an "Open-source AI agent for investigating production incidents and finding root causes", and states that it is a CNCF Sandbox project originally created by Robusta, with major contributions from Microsoft. Its built-in toolsets include Prometheus, Grafana, Datadog, AWS, Azure, GCP, Elasticsearch, Kafka, SQL databases and GitHub. The README states "By design, HolmesGPT has read-only access and respects RBAC permissions", and it also lists an optional Kubernetes Remediation toolset for scaling, rollbacks and resource edits, plus an Operator mode that runs in the background, messages you in Slack and, with the GitHub integration, "can even open PRs to fix what it finds." Slack is available via Robusta.

In our lab, on the same 19 faults with the same model as Aurora, HolmesGPT was correct in 31 of 38 runs, partial in 6 and wrong in 1. Those grades are judge-model only (second-model review and blinded regrade, no person yet). Its median time was 45 seconds against Aurora's 153.5, about 3x faster. If speed of a Kubernetes-plus-observability investigation is what you want, it is the first one to try. For more on the two CNCF tools, see HolmesGPT vs K8sGPT.

Aurora

Aurora is an Apache 2.0, self-hosted AI SRE (Docker Compose or Helm). It takes alerts by webhook from tools such as PagerDuty, Datadog and Grafana, investigates across AWS, Azure, GCP, OVH, Scaleway, Fly.io and Kubernetes, and writes a root cause analysis with a separate list of suggested next steps. It can open a remediation PR on GitHub after a person approves it; it does not auto-merge. It works with your own LLM, including local models through Ollama, and has a Slack integration and an MCP server.

In the lab Aurora was correct in 34 of 38 runs and partial in 4, all read by a person, at a median of 153.5 seconds and $0.35 per investigation. Against HolmesGPT's 31, that gap is not significant (two-sided Fisher exact test on correct against not correct, p = 0.52, the same calculation the benchmark page runs on these totals), so read the two as roughly even on accuracy, with HolmesGPT faster. The prompts differed slightly: Aurora got the alert plus "Investigate and find the root cause", HolmesGPT the alert plus "Find the root cause and say what changed". Every Aurora trace and miss is in the lab report.

kagent

kagent is "a Kubernetes native framework for building AI agents", a CNCF Sandbox project since 22 May 2025. Agents are defined in YAML and managed with kubectl. It ships an MCP server with tools for Kubernetes, Istio, Helm, Argo, Prometheus, Grafana and Cilium, supports OpenAI, Azure OpenAI, Anthropic, Vertex AI and Ollama, and exposes agents through a web UI, a CLI and gRPC, A2A and MCP APIs. It is a framework rather than a finished incident investigator, so it suits teams that want to write their own agents. We did not test it.

Robusta

Robusta (MIT) takes Prometheus alerts and adds pod logs, graphs and possible remediations, then delivers them to Slack, Microsoft Teams and other sinks with grouping into threads. It supports self-healing through auto-remediation rules you define, and HolmesGPT as optional AI investigation. A free hosted Robusta UI adds an alert timeline across clusters. If your complaint about K8sGPT is that findings do not reach the on-call channel with context, this is the closest fit. We did not test it.

Komodor AI SRE

Komodor's incident management module is part of its commercial AI SRE family. Its docs say observability, Kubernetes and cloud investigators gather evidence in parallel, and that it will "Propose the fix and route it for approval before anything is applied", with optional Slack posting. We did not test it and have no numbers for it.

How do K8sGPT, HolmesGPT and Aurora compare on governance?

The K8sGPT operator's own docs say "Status: Alpha. Auto remediation is experimental and must not be relied on for production changes without independent review." For a deeper three-way comparison, see open-source AI SRE: Aurora vs HolmesGPT vs K8sGPT.

What did we not test?

We did not test kagent, Robusta or Komodor. We did not run K8sGPT with optional analyzers (NetworkPolicy, Log) enabled, on Claude Sonnet 5, or with the operator. The lab has no faults outside Kubernetes. All 19 scenarios were written by Arvo. Rerun any of it from the lab repo, or paste your own kubectl describe output into the Kubernetes pod diagnoser to see a likely cause.

Sources and verification

K8sGPT and HolmesGPT runs on 2026-10-15 and 2026-10-16, run folders under runs/h2h-v1/r1 and r2; Aurora runs on 2026-10-02, under runs/v0-run2 and runs/v1-run1, all in aurora-lab. Numbers from the benchmark results file generated 2026-10-21. Tool docs checked 2026-10-21: K8sGPT, k8sgpt-operator, HolmesGPT, kagent, Robusta, Komodor docs, CNCF K8sGPT, CNCF kagent.

If Aurora fits, it is on GitHub, or book a demo.