Incident review

Incident review

When to use

Use this skill after or during a contained incident when people need a trustworthy timeline, impact record, contributing-conditions analysis, and prevention follow-up.

Do not use it as a substitute for live containment, paging, emergency escalation, or security/legal reporting. Not for attributing personal blame, filling gaps with a plausible root cause, or reviewing an event without cited evidence.

Inputs and source discipline

Collect an incident identifier, review scope, start and end bounds, affected systems, and the review as-of date/time. Use a named IANA timezone when available and preserve each source's original timestamp and timezone or offset.

Create an evidence ledger for logs, alerts, deploy records, traces, tickets, support reports, communications, and interviews. For every event or impact claim record the source, source date, as-of date/time, locator, timestamp precision, and freshness. Record missing sources and access limits as unknown rather than compensating with memory. Keep raw evidence separate from analysis.

Method

1. Define the incident boundary and affected service or users from cited evidence. Do not invent severity, duration, counts, percentages, or business impact.
2. Build a timezone-aware timeline. Preserve the reported timestamp and timezone, add a normalized timestamp only when conversion is valid, and cite the source for every row. If two credible sources disagree, retain both rows and mark the point contradictory instead of forcing an order.
3. Separate facts (directly observed or cited), hypotheses (inferred explanations), unknowns, stale evidence, and contradictions. Test a hypothesis against available evidence; do not call it a cause or root cause until the evidence supports that wording.
4. Use a blameless method: describe system conditions, incentives, interfaces, safeguards, detection, response, and recovery. Name actions and controls, not people as the cause. Explain what was reasonable to know at the time.