---
name: incident-triage-brief
description: Turn messy production incident evidence, alert payloads, logs, metrics, traces, deploy notes, customer reports, and on-call Slack updates into a Technical Analyst incident triage brief. Use this whenever a Technical Analyst, SRE, support engineer, engineering manager, or on-call lead needs to summarize symptoms, impact, timeline, likely causes, evidence quality, confidence, gaps, and next investigation steps before escalation, handoff, mitigation review, or post-incident analysis.
---

# Incident Triage Brief

## Intended User Role

Technical Analyst

## Workflow It Solves

Convert scattered incident evidence into a structured triage brief that helps engineering, SRE, support, product, and leadership understand what is happening, what is known, what is only suspected, and what investigation or mitigation should happen next.

This skill is for analysis and handoff. It does not declare incidents, operate production systems, execute remediation commands, write customer-facing status updates without review, or replace the incident commander.

## Required Inputs

- Incident evidence such as alert payloads, logs, metrics, traces, deployment notes, feature-flag changes, support tickets, customer reports, status page notes, Slack updates, runbook notes, or database/API error samples.
- Service context if available: affected service, environment, region, dependency, release version, owner, SLO/SLA target, severity policy, traffic pattern, or recent operational change.
- Timing context if available: first alert, first customer report, deploy window, recurrence pattern, mitigation attempts, recovery time, or timezone.
- Audience and handoff target if available: SRE, backend team, frontend team, data platform, support leadership, incident commander, executive update, or post-incident review.

If evidence is incomplete, proceed with labeled gaps. Ask a clarifying question only when missing information blocks basic impact assessment, prevents separating evidence from speculation, or changes the recommended escalation path.

## Expected Outputs

Produce an incident triage package with:

- Executive summary: service, user impact, current state, likely cause category, confidence, and immediate recommendation.
- Evidence inventory: source, timestamp, signal type, relevant observation, and reliability of each input.
- Timeline: ordered events from first known signal through current status, with unknown or approximate times clearly labeled.
- Impact assessment: affected users, regions, endpoints, workflows, severity, SLO/SLA exposure, customer impact, support volume, and business risk when available.
- Symptom-to-evidence matrix: symptoms mapped to logs, metrics, traces, deploys, customer reports, and attempted mitigations.
- Hypotheses: likely causes, supporting evidence, contradicting evidence, confidence, and the next check that would confirm or reject each hypothesis.
- Known gaps and ambiguity: missing logs, unverified assumptions, clock-skew issues, sampling limitations, unclear ownership, data retention risks, or timeline conflicts.
- Recommended next actions: owner, action, urgency, rationale, and dependency.
- Escalation or handoff note ready to paste into an internal channel.

## Procedure

1. Identify the service, environment, incident window, current state, audience, and decision the brief should support.
2. Separate evidence from interpretation. Treat log lines, metric values, deploy timestamps, trace spans, customer reports, and observed error messages as evidence. Treat root cause statements, severity labels, ownership claims, and broad explanations as hypotheses until supported.
3. Build a timeline before choosing a likely cause. Incidents are often misread when deploys, traffic spikes, dependency failures, and customer reports are compared out of order.
4. Normalize timestamps and call out timezone assumptions. If sources disagree, keep both values and explain the conflict rather than silently choosing one.
5. Inventory the evidence by signal type:
   - Alerts and metrics: rate, saturation, latency, error percentage, queue depth, resource use, SLO burn, anomaly window.
   - Logs: error class, status code, request ID, tenant/customer, endpoint, region, version, retry behavior, volume.
   - Traces: slow span, failed dependency, timeout, retry loop, fan-out, queue wait, cold start, missing instrumentation.
   - Changes: deploy, rollback, migration, configuration, feature flag, infrastructure change, dependency version, traffic routing.
   - Human reports: customer symptom, internal reproduction, support volume, business workflow affected, workaround status.
6. Assess impact conservatively. If counts, regions, plans, tenants, revenue exposure, or SLO windows are unknown, state what is unknown and avoid inventing severity.
7. Form two to four hypotheses. For each one, include:
   - Cause category: deploy regression, dependency outage, data issue, traffic spike, capacity, configuration, auth, network, queue/backpressure, client-side issue, third-party integration, or unknown.
   - Supporting evidence.
   - Contradicting or missing evidence.
   - Confidence: high, medium, low, or speculative.
   - One concrete next check.
8. Watch for common false certainty traps:
   - A deploy near the incident window is not root cause by itself.
   - Customer reports can reveal impact but rarely prove the technical cause alone.
   - A single log sample may not represent the dominant failure mode.
   - A recovery after rollback suggests but does not prove causality.
   - A dependency alert may be a downstream symptom.
9. Recommend next actions that reduce uncertainty or reduce impact. Prefer actions that name an owner or owning team. Mark owner as `Unknown` only when no ownership evidence exists.
10. Draft the handoff note with enough context for another responder to act without rereading every source.

## Quality Checks

Before finalizing, verify that:

- The likely cause is labeled as a hypothesis unless the evidence is strong enough to support it.
- The summary does not overstate severity, blast radius, recovery, customer impact, or SLA exposure.
- The timeline includes deploys, alerts, customer reports, mitigations, and recovery signals when provided.
- Each hypothesis includes supporting evidence, missing or contradictory evidence, confidence, and a next check.
- The brief distinguishes immediate mitigation from longer-term root-cause investigation.
- Known gaps are concrete and actionable, not generic requests for "more data."
- Recommended next actions name an owner or explicitly mark ownership as unknown.
- The handoff note is paste-ready and avoids blame, unsupported certainty, and private customer details unless the user included them for an internal audience.

## Example Task

User prompt:

```text
I am the technical analyst on an active checkout incident. Please turn this into a triage brief for the SRE and payments teams.

Alerts:
- 09:14 UTC: checkout-api 5xx rate crossed 7%, normally below 0.3%.
- 09:17 UTC: p95 latency increased from 420 ms to 3.8 s.
- EU region looks worse than US.

Recent changes:
- checkout-api v2026.08.01.3 deployed at 09:05 UTC.
- Feature flag `payment_orchestrator_v2` enabled for 25% of EU traffic at 09:08 UTC.

Logs:
- Many request IDs show `PaymentProviderTimeout after 2500ms`.
- Some requests retry three times and then return 502.
- Inventory service latency is normal.

Customer reports:
- Support has 18 tickets from EU merchants saying cards spin and then fail.
- One US enterprise merchant reports intermittent failures but support cannot reproduce.

Mitigation:
- SRE disabled the flag at 09:31 UTC. 5xx fell to 1.1% by 09:38 but p95 is still 1.4 s.
```

Expected behavior:

- Create a concise triage brief with current state, impact, and likely cause category.
- Build a timeline from deploy, flag enablement, alerts, customer reports, mitigation, and partial recovery.
- Treat `payment_orchestrator_v2` as the leading hypothesis because timing and recovery support it, but note that residual latency means the provider timeout or retry behavior still needs investigation.
- Mark EU impact as better-supported than US impact.
- Include next checks for payment-provider metrics, flag exposure logs, retry behavior, trace spans, and rollback/deploy comparison.
- Draft a paste-ready internal handoff note for SRE and payments.