Build an incident timeline and postmortem

Why use this

1. After an incident, team members may remember different sequences while alerts, chat and local evidence use inconsistent timestamps. A concise postmortem can become misleading if it turns temporal proximity into a causal explanation.

2. This job could assemble an evidence-linked chronology and a draft that separates established events from unresolved hypotheses. Making proposed actions and owners explicit supports a review discussion without silently assigning blame or commitments.

Why an agent / simpler alternative

Useful judgment

Reconcile timestamps and conflicting accounts, distinguish observations from causes and identify questions requiring human judgment.

Simpler alternative

Use a standard incident form when one complete timeline already exists.

Unsuitable when

The evidence is incomplete but the task demands certainty, blame or unapproved operational changes.

Proposed inputs

1. Name

   Incident evidence

   Owner

   Incident lead

   Minimum scope

   Approved alerts, messages and logs for a bounded window

   Quality check

   Record timezone, clock source and missing intervals

2. Name

   Review brief

   Owner

   Incident owner

   Minimum scope

   Scope, known impact and proposed participants

   Quality check

   Separate confirmed facts from recollections

Access and setup — proposed or unknown

Proposed minimum

1. Read copies of scoped evidence and write a private draft; no paging, channel posting or system changes.

Compatibility unknowns

1. Current connector access, timestamp normalization and exact runtime compatibility are unknown.

External actions requiring approval

1. Publishing the postmortem, assigning work, posting channel notes or disclosing sensitive logs requires approval.

Expected deliverable and review checks

Proposed artifact

Timeline, causal hypotheses, evidence gaps and proposed action-owner table with an unsent channel note.

Critical checks

1. Trace event times; distinguish mitigation from recovery; verify owner acceptance before treating tasks as commitments.

Missing output evidence

This overlay adds no new output inspection, execution or validation; consult the referenced canonical source outcome limits.

Failure signals and proposed responses

1. Signal

   One clock is offset

   Why it matters

   The reconstructed order may reverse cause and effect

   Proposed response

   Retain original times and document unresolved normalization.

2. Signal

   A chat suspicion becomes the root cause

   Why it matters

   Tentative discussion becomes a false finding

   Proposed response

   Keep it a hypothesis and identify supporting or contradicting evidence.

Effort and cost — unknown

Setup work

1. Define the evidence window and timeline conventions.

Ongoing review

1. Review impact, causality and proposed ownership with participants.

Unknowns

1. Evidence completeness, log retention, review effort and service costs are unknown.

First check — proposed, unexecuted

Status

proposed_unexecuted

Synthetic fixture

Invent an alert, chat sequence and log excerpt with one timestamp conflict and one unconfirmed causal claim.

Acceptance checks

1. Expose the conflict; label hypotheses; leave owners proposed; send no channel note.

Stop conditions

1. Stop if protected logs would be exposed or missing evidence makes a definitive conclusion impossible.

Limits

1. A coherent narrative does not establish causality, accountability or acceptance of remediation work.