AIOps RCA Tools 2026: Pricing, Open Source, 3 Tested

Automated root cause analysis is sold in four ways in October 2026. It comes bundled into an observability platform's host or usage price (Dynatrace Full-Stack Monitoring, Datadog Watchdog RCA with APM, Grafana Sift). The newer agentic investigations are metered per use, in credits, AI units, tokens or compute units; where a vendor publishes average consumption, our arithmetic puts it at about $3 (Dynatrace: 30 AI units at $0.10) to $6.50 or $8.45 (Datadog: about 6.5 credits at $1 or $1.30) per investigation. Enterprise AIOps (BigPanda, ScienceLogic Skylar Advisor, Splunk ITSI, Traversal) is quote-only, on annual commitments. Open source agents (Aurora, HolmesGPT, K8sGPT) cost nothing to license; you pay the model provider and run them yourself.

Price tells you little about whether an RCA is right. Of the commercial tools below, only Coroot publishes a benchmark a buyer can rerun (five OpenTelemetry Demo failures); Traversal publishes one on 25 private incidents, and the rest publish none we found. So we measured the open source agents. On the same 19 injected Kubernetes faults, two runs each, Aurora was graded correct in 34 of 38 runs, partial in 4 and wrong in 0, with every grade read by a person. HolmesGPT was correct in 31 of 38 on judge-model grades that no person has checked yet, and it was about 3x faster. Arvo builds Aurora and wrote the scenarios. All runs, partial and wrong answers included, are at /benchmark and in Arvo-AI/aurora-lab.

Which observability platforms have RCA built in?

Every price and feature name below was read on the vendor's own pricing page or docs on 2026-10-21. Several names changed in 2026: Dynatrace's Davis AI docs now redirect to Dynatrace Intelligence, Datadog's Bits AI SRE pages redirect to Bits Investigation, and New Relic's SRE Agent is now Autopilot.

Event-correlation and enterprise AIOps platforms, which sit across many monitoring tools rather than collecting telemetry themselves:

How are automated RCA features licensed and priced?

List prices as published on 2026-10-21. "Per investigation" figures marked as our arithmetic multiply the vendor's published average consumption by its published unit price; actual consumption varies, as every vendor here says.

Three things the table hides. First, the per-investigation numbers are averages the vendors publish "for reference"; a long investigation costs more. Second, several platforms only run agentic RCA on data they already store, so the real cost includes the ingest or host fees underneath. Third, open source is not free to run: in our lab, Aurora's background discovery job (prediscovery), which Aurora schedules after each cluster connection, cost about $1 a connection, almost twice what all 44 investigations cost together ($30.38 against $16.77; the 44 are the 38 graded runs plus 6 check runs the same day). Budget for the model and for the background work, not just the RCA calls.

Which RCA tools are free or open source in 2026?

Free commercial tiers that include some RCA: Grafana Cloud Free (Sift and token-limited Investigations) and Coroot Cloud's 10 investigations a month. Datadog's and New Relic's free tiers exist, but their agentic RCA (Bits Investigation, Autopilot) is paid. PagerDuty Free has no RCA features.

How do you tell whether an AI RCA is accurate and explainable?

This is where tools differ most, and where pricing pages say nothing. Our position: do not buy an RCA you cannot audit. Three checks separate an explainable RCA from a confident paragraph, and you can run all three in a trial.

1. Every claim cites evidence, and the evidence says what the claim says

Aurora's report numbers its claims against the tool calls that produced them. In scenario 13 of our lab (a NetworkPolicy blocks the api from reaching redis), run 1, the root cause reads in part: "The root cause was a NetworkPolicy named redis in the shop namespace, created at 2026-10-02T20:23:54Z, which restricts ingress to redis:6379 to pods labeled app=worker only [20, 22]. The api pods are labeled app=api, not app=worker [23]". Those numbers are steps in the trace. Step 22 is:

$ kubectl describe networkpolicy redis -n shop
Name:         redis
Namespace:    shop
Created on:   2026-10-02 20:23:54 +0000 UTC
Labels:       <none>
Annotations:  <none>
Spec:
  PodSelector:     app=redis
  Allowing ingress traffic:
    To Port: 6379/TCP
    From:
      PodSelector: app=worker
  Not affecting egress traffic
  Policy Types: Ingress

and step 23 shows both api pods labeled app=api,pod-template-hash=f64486c4c. The claim and the output match, so you can accept the RCA without rerunning anything.

Citations are necessary, not sufficient. In scenario 12, the worker is OOMKilled (the alert) and, separately, the frontend Service selects no pods. Aurora's run 1 found the OOM and then wrote:

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

Steps 5 and 14 are both kubectl get pods -n shop -o wide. Running pods say nothing about whether a Service has endpoints. The citation was real; the inference was not, and a real second outage went unreported in both runs. An auditor who checks what the cited step actually proves catches this in a minute. The fix is in the runbook a second fault the alert does not cover.

2. The full tool-call trace is available

You should be able to see every command the agent ran, in order, with its output. Aurora's scenario 13 run made 25 tool calls in 202 seconds for $0.69. Nineteen were kubectl commands: pods, events, frontend, api and redis logs, the api code ConfigMap, Services, nodes, and finally get networkpolicies, describe networkpolicy redis and the api pod labels; the other 6 read the incident list, connected clusters and Aurora's memory, and wrote two memory notes. HolmesGPT prints its trace as it goes ("Running tool #1 kubernetes_tabular_query: ..." and so on); its scenario 13 run made 26 tool calls, all of them cluster queries, in 110 seconds and reached the same cause. K8sGPT has no trace in this sense: it runs fixed analyzers, and in scenario 13 it printed "No problems detected", because every object looks healthy to an analyzer.

The trace also shows what the agent could not do. In scenario 19 run 1, Aurora tried to read the live nginx config inside a pod and its read-only command policy blocked it:

$ kubectl exec frontend-76d98597b9-g5zrg -n shop -c frontend -- cat /etc/nginx/conf.d/default.conf
Command blocked by organization policy: Mutating kubectl operations

Its report said the discrepancy "was not fully reconciled", which is the right thing to say. The clue it missed was already in its own get pods output: the failing pod was 9 seconds younger than the healthy one. Good reports also list what was ruled out and what was not checked; Aurora's scenario 13 report has both sections.

3. Accuracy is measured on faults whose cause is known

A citation trail shows you how the agent reasoned on one incident. Only a set of incidents with a known cause tells you how often it is right. Each lab scenario states its required findings and its tempting wrong answers in a file; scenario 13's says:

must_identify:
  - The api cannot reach redis (connection timeouts), which is why /api/ returns 5xx; redis itself is healthy
  - The cause is the NetworkPolicy redis, which allows ingress to redis only from app=worker, not from the api
wrong_answers:
  - redis is down or overloaded
  - DNS failure
  - Restarting the api or redis as the fix

Correct means every required finding stated and no wrong answer asserted; partial means some but not all, or a wrong answer stated alongside the right one. That is the bar we used below.

What did the lab measure for Aurora, HolmesGPT and K8sGPT?

Setup: a small app (shop: nginx frontend, Python api, worker, redis, load generator) on a kind v0.33.0 cluster running Kubernetes v1.37.0 with 3 nodes. Each scenario injects a known fault, and a check script proves the fault is visible before any agent starts. Aurora's runs are from 2026-10-02; HolmesGPT's and K8sGPT's from 2026-10-15 and 2026-10-16, on the same cluster and faults. All three got the same admin kubeconfig, each behind its own guard: Aurora's default read-only observability_only command policy, HolmesGPT's command allow-list, K8sGPT's read-only analyzers. Aurora and HolmesGPT both ran on Claude Sonnet 5 via Bedrock; K8sGPT ran on Sonnet 4.5, because it sends a temperature parameter Bedrock rejects for Sonnet 5.

The prompts differ. Aurora got the alert text plus "Cluster: aurora-lab (kubeconfig). Investigate and find the root cause." HolmesGPT got the alert text plus "Namespace shop, cluster kind-aurora-lab. Find the root cause and say what changed." K8sGPT takes no alert and scanned the namespace.

How the grades were checked. A judge model (Claude Opus 5.5, from the same vendor as every model under test) graded all 114 runs against the injected fault. A person read all 38 Aurora grades. The 76 HolmesGPT and K8sGPT grades are judge-model only: a second model re-read all 76 and agreed with every one, and a third pass graded all 76 from scratch, agreeing on all 38 HolmesGPT verdicts and disputing 6 K8sGPT labels (it would have called them "no answer"). A blinded regrade with agent, tool and cluster names 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. No person has checked the 76 yet.

On correct against not correct, the two-sided Fisher exact test that /benchmark computes on the totals gives p = 0.52 for Aurora against HolmesGPT, comparing person-read Aurora grades with judge-only HolmesGPT grades. Read the two as roughly even on accuracy. HolmesGPT is clearly faster: 45 seconds at the median against Aurora's 153.5. Aurora's times include contention from its own background discovery jobs in the lab, but that does not close a 3x gap.

Aurora's four partial answers

None of Aurora's 38 runs was graded wrong; four were partial:

• Scenario 12, both runs (partial). Found the OOMKilled worker, reported the frontend workloads as healthy or unaffected without checking Services or endpoints, as quoted above. HolmesGPT also found only the OOM in both runs.
• Scenario 19, run 1 (partial). Found the edited ConfigMap but could not work out that only the restarted pod had loaded it. Run 2 got it right with 28 tool calls.
• Scenario 11, run 2 (partial). Found the wrong Service targetPort, but never looked at the worker whose noisy errors were the scenario's red herring; its report says those deployments "were not examined". You could argue it deserves correct, since it was not misled. We kept the rubric as written.

A second-model review also found small claims the evidence did not support in 15 of the 18 reports for scenarios 11 to 19, none of them in the root cause: "both cluster nodes" when there were three, an image "pulled successfully" with no Pulled event, a trend drawn from one sample. That is the kind of hallucination the citation check in section 1 is for. Separately, a grading script found an acceptable fix in Aurora's suggestions in 34 of 38 runs.

HolmesGPT's one wrong verdict was scenario 19, run 1, whose answer opened "All data points to a transient startup race, now resolved." Its second run was correct.

What K8sGPT does and does not do

K8sGPT answers a different question: what looks broken in this namespace? It runs analyzers and has the model explain each finding; it does not take an alert or follow a chain of evidence, so grading it on alert-driven criteria shows what it misses, not that it failed the same task. In 12 of its 38 runs, both runs of 6 scenarios (the wrong liveness port, a wrong targetPort, the NetworkPolicy, a stray Deployment sharing a label, a slow memory leak, the config drift), it printed "No problems detected". Where the fault shows on an object, such as a mistyped image tag, it named it in seconds (graded partial there, because it never said the old pods were still serving). As a cheap cluster scan it is useful; as an RCA tool for an alert it is the wrong fit. More in HolmesGPT vs K8sGPT.

What are the alternatives to Zebrium for log-driven RCA?

ScienceLogic acquired Zebrium on October 11, 2022. In July 2024 ScienceLogic introduced log-based "Skylar Automated Root Cause Analysis (RCA)", and today zebrium.com redirects to ScienceLogic's Skylar Advisor page, so that is where ScienceLogic now points Zebrium's buyers; it is priced by quote. Other options that read logs alongside metrics and traces to propose a cause: Grafana Cloud Investigations (token-priced), Datadog Bits Investigation (credit-priced), Coroot (per core, with 10 free cloud investigations a month), and the open source agents above, which read logs through kubectl and monitoring connectors. Only the last group can be run on your own infrastructure with no vendor account.

How do Traversal, Datadog, Dynatrace and ScienceLogic compare for evidence-backed RCA?

From what each publishes: Dynatrace builds its RCA on a topology model and calls the method deterministic and causation-based; Datadog's Watchdog RCA needs APM data and Bits Investigation runs as an agent over Datadog data; Traversal sells an AI SRE that deploys read-only by default, with private on-premises deployments, your own model and your own cloud account as options; ScienceLogic positions Skylar Advisor on top of Skylar One's device and service data. Traversal's RCA page claims "> 82% Accurate remediation", and Traversal has published a benchmark on 25 real incidents at one unnamed enterprise, judged blind against frontier models given direct tool access; the incidents are private, so a buyer cannot rerun it. BigPanda's page says its RCA "reduces MTTR by up to 50%". Datadog has written about the internal evaluation platform it uses for Bits. We found no public test set for any of these four that a buyer could rerun. Coroot, outside this group, is the exception: its AI RCA benchmark uses five OpenTelemetry Demo failure flags anyone can trigger, and Coroot scores its own RCA 2/3 or 3/3 on each. We have not tested any of them, so we cannot rank them.

How can you test a vendor's RCA in a trial?

Use the lab. It is a kind cluster on one machine; any agent that can read a kubeconfig can be pointed at it, and a SaaS platform needs its own agent or collector installed in the cluster first, so the faults reach it the way they would in production:

git clone https://github.com/Arvo-AI/aurora-lab && cd aurora-lab
./lab.sh up
./lab.sh break 13-networkpolicy-blocks-redis

Then give the trial agent the scenario's alert line from scenarios/13-networkpolicy-blocks-redis/scenario.yaml, and grade its answer against must_identify and wrong_answers in the same file. ./lab.sh break restores the healthy app before injecting each fault, and the cluster's kubeconfig is written to .kubeconfig in the repo. Five scenarios are enough to learn a lot: 03 (bad image tag) is the easy baseline, 12 (two faults) and 19 (partial restart) got partial or wrong answers from both investigation agents we tested, 13 (NetworkPolicy) gave K8sGPT's analyzers nothing to flag, and 17 (slow leak) has clean logs. While you grade, run the three checks above: does each claim cite a step, does the step say what the claim says, and can you see every command. Runbooks for each fault live at /runbooks, and /diagnose walks through a single failure on your own cluster.

Which RCA tool fits which team?

What this does not show

The lab is Kubernetes-only, on a synthetic app, with faults Arvo wrote, two runs per scenario. It says nothing about cloud APIs, logs at production scale or noisy real alerts, and nothing about how any commercial tool would score. HolmesGPT's grades still need a person to read them, and its cost per run was not captured. Vendor prices change often and several are promotional ("for a limited time" at Dynatrace); recheck them before you sign.

For the full method and every trace, see the Aurora lab report and the three-way write-up Aurora vs HolmesGPT vs K8sGPT. For background on the practice itself, Root Cause Analysis: The Complete Guide for SREs; for buying criteria, how to evaluate an AI SRE platform. Vendor-specific comparisons: Dynatrace Davis, Datadog Bits AI SRE, New Relic AI, Splunk ITSI, BigPanda, PagerDuty, Keep vs Aurora.

Verified 2026-10-21: vendor features and prices from each vendor's own pricing page and docs, linked above; benchmark numbers from results.json generated 2026-10-21; Aurora runs on 2026-10-02, HolmesGPT and K8sGPT runs on 2026-10-15 and 2026-10-16.

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