Incident Response·9 min read

Root Cause Analysis

How the RCA Agent builds an evidence-backed hypothesis before an engineer opens a terminal.

Root cause analysis usually starts the same way: an engineer opens five dashboards, greps through logs, and tries to remember whether anything changed recently. PulseServe's RCA Agent runs that process automatically the moment an incident is enriched.

It pulls from a two-hour window of MELT data — metrics, errors, logs, and traces — alongside alert patterns, change correlations, blast radius, and the CI dependency graph. Recent changes are weighted by how recent they are (a change 15 minutes ago scores highest) and how directly they touch the affected CI, so the agent is not just pattern-matching against noise.

What makes the output trustworthy

  • Known Error Database match — if the incident matches an entry in the KEDB, that pre-validated root cause is used and confidence is automatically set to 0.9 or higher.
  • Cascade siblings — the agent checks for other incidents firing from the same blast-radius group, because incidents that share a blast radius are a strong signal they share a root cause.
  • Few-shot learning from your own history — past RCAs that a human has already approved are fed back in as examples, so reasoning quality improves with every incident your team confirms.

Output shape

The result is structured, not a paragraph of prose: a root cause hypothesis, a confidence score, an evidence chain a reviewer can actually check, immediate actions, prevention steps, and suggested knowledge-base article titles so the fix gets documented as a byproduct of resolving it.

None of this replaces the engineer — it replaces the twenty minutes of dashboard-hopping that used to happen before the engineer could start actually thinking about the fix.

Reading an RCA result

Open the incident's AI Analytics tab and scroll to the RCA section for the root cause description, contributing factors, a confidence score, and a "similar past incidents" list when a vector match is found. Confidence is color-coded so you can triage attention at a glance: green at 75% or above, amber from 55–74%, red below 55%.

Investigating manually alongside the agent

When you want to check the agent's work — or the confidence is too low to trust outright — open MELT, the same signal source the RCA agent reads from: the Signals tab for a raw metrics/logs/events search around the incident time, the Traces tab to walk a specific slow or failed request step by step, and Predictive Warnings for anything the platform already flagged before the incident happened. See MELT: Metrics, Events, Logs & Traces for the full picture.

Where the evidence comes from

RCA doesn't reason from the incident description alone — it pulls together several sources at once, the same ones a human would check manually:

  • Live system telemetry — the metrics, logs, and traces flowing in through MELT around the time the incident started.
  • The CMDB dependency map — what the affected system connects to, so the agent knows what's actually at risk, not just what's directly reporting an error.
  • Recent changes — deployments or configuration changes near the affected system, weighted by how recent and how closely they touch it.
  • Related incidents — other tickets sharing the same blast radius, since that's a strong hint they share a cause.
  • Your team's own history — previously confirmed root causes in the Known Error Database, and past RCAs your team has already approved.

Setting up for full RCA coverage

RCA quality depends almost entirely on how much evidence is available when an incident happens — not the AI itself — and that comes down to how the platform is set up beforehand:

  1. Connect your monitoring stack — send metrics, logs, and traces in from the tools you already run (see the Ingest Guide tab on the MELT page). Without this, RCA has little more to work with than the ticket text.
  2. Keep your CMDB populated — add your systems and how they depend on each other, or let PulseServe build this automatically by observing traffic between them over time (see CMDB & Blast Radius). A system missing from the CMDB is invisible to dependency and blast-radius reasoning.
  3. Record your changes and deployments — logging what changed and when lets RCA correlate an incident with a likely cause instead of guessing blind.
  4. Review and approve RCA results as they come in — approving, rejecting, or refining outcomes (see Remediation & Human-in-the-Loop) feeds directly back into future analyses, so accuracy improves the more your team uses it.
An incident's Root Cause tab shows a plain-language indicator of how much reliable evidence was actually available — for example, calling out that traces were missing or the data was too old to fully trust. If that gap is severe enough, the incident is automatically routed for human review instead of the pipeline completing on its own.

Example

"App team reports slow response times on payment service." The Correlation tab shows a database server CPU alert alongside a recent schema-migration change in the same window. RCA returns: "Schema migration added a missing index — full table scan causing timeouts," at 82% confidence (green). The suggested remediation: add an index on the affected column and restart the query cache.

← PreviousAI Triage & RoutingNext →Remediation & Human-in-the-Loop