Skip to main content

Root Cause Analysis

InfraSage's RCA is an investigating agent, not a summarizer. It decides what evidence it needs, gathers it, and writes a conclusion it has to support with that evidence. A deterministic origin finder keeps it honest, and an independent reviewer checks its work.

How an analysis runs​

RCA is started by a person or a webhook. The platform never spends on analysis 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. Where it started. Before any AI model is involved, InfraSage works out from your dependency topology which service most likely started the trouble, and which loud services could not have, because they went wrong after the services that depend on them. The agent starts from that verdict and may overrule it only by citing evidence that contradicts it.
  2. What changed. The service's recent deploys, config changes, feature flags and scale events around the start of the trouble are always part of the investigation, and the agent is asked to cite any version that plausibly explains it. (Change Intelligence)
  3. The evidence. The agent can query metrics, search logs, follow traces, check the blast radius and dependency topology, look at SLO burn, compare with past incidents and anomalies happening at the same time, review deploy history and forecasts, find remediation candidates, and check whether telemetry coverage is good enough to trust. In federated mode, log and trace queries go to your stack.
  4. The answer. A written analysis with the likely root cause, the evidence for each signal, 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. When there is no clean origin signal, the analysis says so, with a machine-readable reason and a human explanation. Evidence lands a few minutes behind live data, so for very recent trouble "re-run shortly" is often the truthful answer, and the API says exactly that.
  • A second opinion. An independent reviewer checks each analysis against the deterministic evidence and records whether it agrees and how confident it is.
  • Degraded-mode labeling. If the AI provider is unavailable, a rule-based fallback still produces a basic analysis. It is permanently labeled analysis_mode: fallback_rules, bannered in the console, and excluded from AI-accuracy metrics, so you always know which kind of answer you're reading.
  • Feedback loops. A thumbs-down correction shapes future analyses for that service. Accuracy metrics on the Insights page are computed from benchmark scenarios and labeled as such.

Cost discipline​

InfraSage uses fewer AI tokens than other AI SRE tools: the agent investigates from evidence InfraSage has already distilled, not from 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 fault-injection scenarios on the InfraSage pilot: 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.