Incident timeline and postmortem template

Start with a blank review

Edits stay in this page’s memory. They are not saved, uploaded or added to the URL. Download or copy before leaving. Use service aliases and owner roles; do not enter secrets, customer identifiers, private links or raw logs. Exports are not automatically redacted.

Download blank Markdown or download the fictional example.

Printable worksheet

# Incident timeline and postmortem

## Summary and impact

- Incident title / reference:
- Review date / author role:
- Status (ongoing, recovered, under review):
- Affected service alias / user-visible symptom:
- Impact start / end (timestamp with UTC offset):
- Scope and duration (observed / estimated / unknown):
- Evidence reference (sanitized; no private URLs or logs):

## Timeline

Use YYYY-MM-DDTHH:mm:ssZ for UTC, or an explicit offset such as +02:00.
Mark each entry Observed, Action, Hypothesis (unverified), or Unknown.
Do not invent timestamps; label approximate times and clock uncertainty.

- [timestamp + offset] | [type] | [observation or action] | [owner role] | [evidence reference]
- [timestamp + offset] | [type] | [observation or action] | [owner role] | [evidence reference]
- [timestamp + offset] | [type] | [observation or action] | [owner role] | [evidence reference]

## Recovery and validation

- Mitigation / action / owner role:
- Recovery check and observation window:
- Evidence of restored user-visible behavior:
- Remaining risk / rollback condition:

## Contributing factors and unknowns

- Confirmed factor and supporting evidence:
- Hypothesis (unverified) / supporting and contradicting observations:
- What evidence would confirm or reject it:
- Unknown / next investigation / owner role:
  Do not treat events happening together as proof of cause. Root cause may remain unknown.

## Follow-up evidence

- Action / owner role / due date:
- Measurable completion criterion / evidence reference:
- Verification result / reviewed date:
- Next review / unresolved questions:

Before sharing: remove credentials, hostnames, IP addresses, customer identifiers,
private links and raw logs. Use roles and service aliases. Review exports yourself;
this template does not detect or redact secrets.

Fictional worked example

An original practice incident, not a real customer report. Recovery after a revert is an observation; it does not prove why recovery happened. The hypothesis stays unverified and follow-up actions stay open.

# Fictional example: delayed sample dashboard updates

## Summary and impact

- Reference: practice-01; review date: 2026-10-21; author role: duty operator.
- Status: recovered, cause under review. All services and evidence below are invented.
- Service alias: sample dashboard. A manual refresh displayed an older sample reading.
- Observed window: 2026-10-20T09:00:00Z to 2026-10-20T09:12:00Z (12 minutes).
- Scope: one practice dashboard observed; wider impact and exact start are unknown.
- Evidence: fictional notes A and B; no real logs, hostnames or customer records.

## Timeline (UTC)

- 2026-10-20T09:00:00Z | Observed | Manual refresh still showed the 08:55 sample reading | duty operator | note A
- 2026-10-20T09:03:00Z | Observed | Sample collector queue contained 8 pending items | duty operator | note A
- 2026-10-20T09:05:00Z | Hypothesis (unverified) | A recent polling change may have delayed collection; timing alone does not prove this | investigator | note A
- 2026-10-20T09:07:00Z | Action | Reverted the practice polling change | duty operator | note B
- 2026-10-20T09:12:00Z | Observed | Manual refresh displayed a new 09:12 sample reading | duty operator | note B
- 2026-10-20T09:17:00Z | Observed | Five further one-minute checks each displayed a new reading | duty operator | note B

## Recovery and validation

- Mitigation: practice configuration reverted by duty operator at 09:07 UTC.
- New readings observed from 09:12 through 09:17 UTC; this supports recovery in that window only.
- Remaining risk: delayed collection could recur; resume investigation if readings stop advancing.

## Contributing factors and unknowns

- Confirmed observation: queued items and stale readings occurred in the same window.
- Hypothesis (unverified): polling change contributed to queue growth.
- Supporting observation: readings resumed after the revert.
- Counterevidence / limitation: queue drainage or another unobserved change could also explain recovery.
- Root cause remains unknown. No controlled comparison or collector timing evidence exists yet.

## Follow-up evidence

- Investigator, due 2026-10-22: compare old/new polling settings in an isolated sample environment.
- Completion criterion: record queue depth and reading age for both settings under equal sample load;
  accept or reject the hypothesis only if the evidence supports it. No result is claimed yet.
- Duty operator, due 2026-10-22: draft a stale-reading check and demonstrate a sample failure/recovery.
- Next review: 2026-10-23; both actions remain open in this fictional example.

Write an evidence-led review

Use timestamps with a timezone

Write a full date and time with Z for UTC (2026-10-20T09:00:00Z), or an explicit offset (2026-10-20T11:00:00+02:00 describes the same instant). Record original offsets and clock uncertainty. Mark approximate times; leave unknown times unknown. A monitoring alert time may differ from the start of user impact.

Separate observations from explanations

Observed means you can name the supporting evidence. Action records what changed and who owned it. Hypothesis (unverified) means a possible explanation still needs a test. Unknown is a useful answer. Write what would disprove a theory and avoid assigning blame or treating correlation as a proved cause.

Close actions with evidence

Give each follow-up an owner role, due date and measurable completion criterion. “Improve monitoring” is incomplete; “demonstrate a stale-reading alert in a sample environment and record detection time” can be checked. Reference sanitized evidence, not credentials or private logs.

Use the timestamp converter to reconcile offsets and the recovery objectives worksheet to compare recovery targets with test evidence.

Check current observations

ObserveifyNow offers free anonymous reads of published Uptime Kuma status pages in the browser. Protected infrastructure reads require the native app, whose distribution is still in development. It does not ingest this review or prove incident causality.