Incident Response·10 min read

AI Analytics: From Evidence to Recovery

Read the analysis summary and 15-step log, distinguish model confidence from evidence quality, and understand approval and verification.

Inside Incident 360, open AI Analytics. Start with the summary, then expand the analysis log and its four groups. This view explains how the investigation arrived at its conclusion; it also exposes the human decisions and recovery results associated with the run.

These are actual PulseServe screens rendered with fictional documentation fixtures. INC0000001 uses the seeded checkout outage scenario; the related problem, change plans, users, and dates are illustrative. This resolved example shows a completed investigation. Available tabs and actions depend on your role, permissions, configuration, and ticket state.
AI analysis summary presenting the checkout root cause, confidence, supporting evidence, and recommended next step.
The summary is the starting point. Follow its evidence and review links into the relevant steps of the analysis log. Select the image to view it full size.

Steps 1–5: establish the incident and evidence quality

  • Step 1 receives the incident; step 2 validates its affected CI or service. Correct an uncertain CI before trusting topology-based conclusions.
  • Step 3 defines the evidence window; step 4 gathers Metrics, Events, Logs, and Traces (MELT). The time window matters because unrelated deployments and alerts can look similar.
  • Step 5 checks completeness and quality. Missing traces, sparse metrics, stale data, or clock issues can weaken the result. Evidence quality measures the inputs; model confidence measures the conclusion.
AI analysis steps one through five showing incident identity, CI, telemetry window, and evidence quality.
Signals and data quality: the demo evidence quality is 91%. That is distinct from the 88% root-cause confidence. Select the image to view it full size.

Steps 6–10: connect signals and rank explanations

  • Step 6 detects anomalies. Connection-wait p95 rises from 2 ms to 890 ms in this example.
  • Step 7 links logs and traces to the same request or entity: POST /checkout contains a connection-pool exhaustion error.
  • Step 8 compares changes, deployments, and topology. The v2.4.1 deployment is a strong candidate because it affected the same CI and preceded the incident by 22 minutes.
  • Step 9 builds the timeline and failure chain: deploy → N+1 queries → connection pool exhaustion → HTTP 500 responses.
  • Step 10 ranks hypotheses. The leading deployment hypothesis scores 0.88; the alternative known-error recurrence scores 0.35 and has contradictory evidence. Read supporting and contradictory evidence before accepting the ranking.
AI correlation and hypothesis group linking a connection-wait anomaly, failing checkout trace, deployment, timeline, and ranked hypotheses.
Correlation and hypotheses: timing and entity overlap support an explanation, while contradictions help rule out alternatives. Select the image to view it full size.

Steps 11–12: review the conclusion and approval

Step 11 combines the evidence into a root cause, business impact, immediate action, contributing factors, and prevention steps. The dependency context graph adds relationships and investigation context. Step 12 records review or controlled automation. The demo RCA was approved after the production-environment rule required human review.

Root cause and approval group showing deployment diagnosis, evidence chain, prevention steps, and recorded review.
The model proposes an N+1 query regression. Approval of that diagnosis and authorization of remediation steps are separate decisions. Select the image to view it full size.
  • Approve the RCA when its evidence supports the conclusion; reject it with a reason when it does not; refine it when the human conclusion differs.
  • Inspect each remediation step, its blast radius, rollback possibility, and change-ticket requirement. Approving an explanation does not make every proposed production action appropriate.
  • The log, controls, and findings visible to a responder depend on their persona and permissions. These snapshots use the administrator view.

Steps 13–15: act, verify, and retain the outcome

Step 13 recommends a runbook or resolution. Step 14 verifies recovery through telemetry associated with a live execution. Step 15 retains the incident evidence and learning context. A completed pipeline and a recovered service are different outcomes: inspect the execution verification before deciding the incident is ready to resolve.

Recommendation and recovery steps showing rollback guidance, execution status, and a resolved recovery verdict.
The demo live execution is completed and verification is RESOLVED. Its recovery comparison is separate from the earlier deployment comparison. Select the image to view it full size.
The deployment comparison measures the suspected release: error rate increased from 2% to 40% in this seeded comparison. The recovery comparison measures the intervention: 40% to 0.3%. These describe different windows and must not be combined into one before/after claim.
  • RESOLVED: the recovery criteria are satisfied. Confirm functional recovery too.
  • PARTIALLY_RESOLVED or NO_IMPROVEMENT: keep investigating the remaining impact.
  • REGRESSION: the intervention worsened the measured condition; review rollback and the next investigation.
  • VERIFICATION_INCONCLUSIVE: the available evidence cannot establish recovery. Do not interpret missing data as success.

Use the RCA report download when you need to share the investigation. Review its contents and recipients before sharing, because a live report can include ticket text, component names, and evidence.

The complete populated incidentRCA inputs and evidenceRemediation and human reviewConfigure review thresholdsTry the seeded scenario
← PreviousRoot Cause AnalysisNext →Remediation & Human-in-the-Loop