Playbook vs timeline?

The playbook is what to do next. The timeline is what already happened.

How detailed should Low incidents be?

A few bullets are enough. Reserve full tables for High/Critical customer-visible incidents.

Is the timeline customer-visible?

No. Only status-page updates you publish are public. The timeline is for your team.

Preview or copy each section below. Paste into Notion, Confluence, or your wiki.

Timeline log

Incident timeline

Facts, not chat logs. One line per meaningful event.

Field	Value
Incident	[Title]
Deduplication key	[key]
Timezone	[Europe/Zurich]
Log owner	[Name: keeps this current during the incident]

Live log

Time	Who	Type	What happened
HH:MM	Monitor	Detection	Alert: [name], [symptom]
HH:MM	[Name]	Triage	Declared. Severity [X]. Components: [list]
HH:MM	System	Escalation	Paged [policy] → [Name] acknowledged
HH:MM	[Name]	Investigation	Hypothesis: [cause]. Checking [metric/deploy]
HH:MM	[Name]	Decision	Roll back [change]
HH:MM	[Name]	Public update	Status page: Investigating: “[summary]“
HH:MM	[Name]	Mitigation	[Action] → [result]
HH:MM	[Name]	Recovery	[Metric/test] normal
HH:MM	[Name]	Public update	Status page: Resolved: “[summary]“
HH:MM	[Name]	Wrap-up	→ Post Incident. Follow-ups: [list]

Entry types

Detection · Triage · Escalation · Investigation · Decision · Mitigation · Public update · Recovery · Wrap-up

Log these

Severity changes · Pages & acks · Published status updates · Mitigations & outcomes · Handoffs

Skip these

Play-by-play chat · Unlabeled speculation · Secrets & customer PII

Follow-up (after impact ends)

Task	Owner	Due
[Add monitor / fix runbook]	[Name]	YYYY-MM-DD

# Incident timeline

> Facts, not chat logs. One line per meaningful event.

## Header
| Field | Value |
|-------|-------|
| Incident | [Title] |
| Deduplication key | [key] |
| Timezone | [Europe/Zurich] |
| Log owner | [Name: keeps this current during the incident] |

---

## Live log
| Time | Who | Type | What happened |
|------|-----|------|---------------|
| HH:MM | Monitor | Detection | Alert: [name], [symptom] |
| HH:MM | [Name] | Triage | Declared. Severity [X]. Components: [list] |
| HH:MM | System | Escalation | Paged [policy] → [Name] acknowledged |
| HH:MM | [Name] | Investigation | Hypothesis: [cause]. Checking [metric/deploy] |
| HH:MM | [Name] | Decision | Roll back [change] |
| HH:MM | [Name] | Public update | Status page: Investigating: "[summary]" |
| HH:MM | [Name] | Mitigation | [Action] → [result] |
| HH:MM | [Name] | Recovery | [Metric/test] normal |
| HH:MM | [Name] | Public update | Status page: Resolved: "[summary]" |
| HH:MM | [Name] | Wrap-up | → Post Incident. Follow-ups: [list] |

### Entry types
`Detection` · `Triage` · `Escalation` · `Investigation` · `Decision` · `Mitigation` · `Public update` · `Recovery` · `Wrap-up`

### Log these
Severity changes · Pages & acks · Published status updates · Mitigations & outcomes · Handoffs

### Skip these
Play-by-play chat · Unlabeled speculation · Secrets & customer PII

---

## Follow-up (after impact ends)
| Task | Owner | Due |
|------|-------|-----|
| [Add monitor / fix runbook] | [Name] | YYYY-MM-DD |

How to use this template

Assign one log owner during the incident, often the commander or a scribe.
Record public updates when sent, not when drafted.
Track follow-ups here; close the incident once tasks are owned.

Incido’s incident timeline captures pages, acknowledgements, stage changes, and published updates automatically. Use manual notes for decisions and hypotheses.

Explore incident management

Incident Timeline Template