Skip to main content

Root Cause Analysis

InfraSage's RCA is an investigating agent, not a summarizer. It decides what evidence it needs, pulls it with real tools, and writes a conclusion it has to support. A deterministic origin resolver keeps it honest, and an independent judge reviews its work.

How an analysis runs​

RCA is human- or webhook-triggered. The platform never burns analysis spend unless an operator or an integration asks for it. Start one from an incident ("Analyze"), from chat, or over the API:

POST /api/v1/rca/analyze   {"service_id": "payment-service", "timestamp": "2026-08-30T01:16:00Z"}
GET  /api/v1/rca/analysis?service=payment-service

The agent then works the case:

  1. Origin resolution runs first, and it is deterministic. Before any LLM call, a graph resolver scans per-metric anomaly rising edges across the calling topology and computes the most likely origin service. It also rejects loud services that couldn't be the cause ("a non-preceding callee cannot be the cause even though its peak z=9.3"). The verdict and its confidence steer the agent, which may overrule it only with explicitly cited contradicting evidence.
  2. Change context is guaranteed, not left to the agent's discretion. The service's deploys, config changes, flags, and scale events (60 min before onset to 5 after) are injected into the investigation up front, with an instruction to cite versions that plausibly explain the anomaly. (Change Intelligence)
  3. The investigation is tool-driven. Seventeen evidence tools: metric queries, log search, traces and blast radius, dependency topology, SLO burn, historical incidents, concurrent anomalies, deploy history, forecasts, remediation candidates, telemetry-coverage checks, and more. In federated mode, the log and trace tools transparently query your stack.
  4. The result is a written analysis with the likely root cause, per-signal evidence scores, upstream suspects, clarifying questions when the evidence is genuinely ambiguous, and suggested actions wired to runbooks.

Answering an analysis's clarifying question re-runs it with your answer as trusted context.

Honesty mechanisms​

  • Abstention over confabulation. No clean origin signal → the resolver abstains with a machine-readable reason and a human explanation. Very recent anchors get a specific hint: evidence lands a few minutes behind live data, so "re-run shortly" is often the truthful answer, and the API says exactly that.
  • The acceptability judge shadow-reviews each analysis against the deterministic evidence and records its agreement and confidence, so there is a second opinion on file.
  • Degraded-mode labeling. If the LLM provider chain is down, a rule-based fallback still produces a basic analysis. It is permanently labeled analysis_mode: fallback_rules, banner'd in the console, and excluded from AI-accuracy metrics, so you always know which kind of answer you're reading.
  • Feedback loops. Thumbs-down corrections become negative exemplars injected into future prompts for that service. Accuracy metrics on the Insights page are computed from benchmark scenarios and labeled as such.

Cost discipline​

InfraSage uses fewer LLM tokens than other AI SRE tools. The deterministic layers (origin resolution, change enrichment, anomaly scoring) do their work as pure computation before any model is invoked, so the agent investigates from pre-distilled evidence rather than raw telemetry dumps. Per-analysis token counts, latency, and estimated cost are recorded on every RCA and rolled up on the Insights page as cost per RCA and 30-day spend, so the numbers are yours to check. Provider circuit breakers, response caching, per-tenant rate limits, and daily budget caps bound the spend. And because analysis is human-triggered, cost tracks how often you ask, not how many alerts fire.

Verified behavior​

From live control scenarios against production: correct origin attribution on injected faults, including explicit rejection of a louder-but-downstream service, and deploy citation by version in the written analysis. In one run the agent identified the fault injection itself, from the chaos tooling's own log lines. Abstentions happen when evidence is thin, and they say so. That is the designed behavior, not a failure mode.