📝 The Incident Scribe: Keeping the Record While Everyone Else Fixes

Two days after a nasty outage, someone opens the postmortem doc and tries to reconstruct what happened from a 400-message channel scrollback, three DM threads, and everyone’s fuzzy memory. The timeline that comes out of that is always wrong in small, important ways — the mitigation went in at 14:32, not “around 2:30ish,” and the thing that actually fixed it wasn’t the change everyone remembers. That reconstruction is painful, slow, and unreliable, and it’s completely avoidable.

The fix is a scribe: one person whose entire job during the incident is to keep the record while everyone else fixes the problem. It’s an unglamorous role that gets skipped constantly, and skipping it is a false economy. A good scribe is the difference between a postmortem that writes itself and a forensic archaeology project. Here’s how to do the role well.

What the scribe actually does

The scribe captures the facts of the response as they happen: what was observed, what was decided, what was tried, and when. That’s it. The scribe is not investigating, not fixing, and not making decisions — which is exactly why the role works. Everyone deep in the fix is too loaded to also keep a clean record; their attention belongs on the problem. The scribe’s detachment from the fixing is the feature.

Concretely, a scribe produces a running, timestamped timeline that serves three audiences at once:

• The responders, who can glance at it to re-anchor on “what have we actually confirmed and tried” instead of holding it all in their heads.
• The incident commander, who uses it to see the current picture without scrolling back through 200 messages.
• The postmortem, which inherits a real-time, accurate timeline instead of a reconstruction.

What to capture (and what to skip)

The scribe’s skill is filtering. A transcript of every message is useless; nobody reads it. Capture the load-bearing moments:

CAPTURE:
- Key observations ("error rate hit 40% at 14:03")
- Severity changes and why
- Decisions made and who made them
- Actions taken (deploys, rollbacks, config changes, restarts)
- Hypotheses raised and ruled in/out
- Handoffs (who took over what, when)
- Customer/comms milestones (status page posted, exec notified)
- The mitigation, the fix, and confirmation it held

SKIP:
- Every "looking..." and "hmm"
- Duplicate chatter
- Speculation not tied to a decision or action

Every entry gets a timestamp. Timestamps are the whole value — a timeline without accurate times is just a list, and the gaps and durations between events are where the postmortem finds its real lessons (“we took 22 minutes to notice, then 4 to fix”).

A live-notes template

Pin this in the incident channel and fill it as you go. It doubles as the skeleton of the postmortem.

INCIDENT TIMELINE — #inc-2026-checkout
Scribe: [name]

14:03  Alert: checkout error rate elevated (>30%).
14:05  [name] declared SEV2, took coordination.
14:07  Impact confirmed: ~all checkout attempts failing.
       Comms: status page updated "investigating".
14:12  Hypothesis: recent payments-service deploy (13:58).
14:15  Decision ([IC]): roll back payments-service deploy.
14:18  Rollback started by [name].
14:24  Error rate dropping. Rollback appears effective.
14:31  Error rate normal for 5+ min. Impact resolved.
14:34  Confirmed holding. Stood down, SEV2 closed.
       Postmortem owner: [name].

OPEN QUESTIONS (for postmortem):
- Why did the deploy pass CI but fail in prod?
- Detection took 0 min (good) — mitigation took 13. Why 13?

Notice the “open questions” section. The scribe is perfectly placed to jot down the things nobody has time to answer mid-incident but will want in the retro. Capturing them live means they don’t evaporate.

Who should scribe

On a larger incident, the scribe should be someone not on the critical debugging path — a second responder, an engineer from an adjacent team, or a manager who wants to be useful without getting in the way. It’s a genuinely great role for someone learning the system, because keeping the timeline forces you to follow the whole response closely.

On a small incident, the coordinator may scribe too, or the responders may drop timestamped notes into the channel themselves as they work. That’s fine, as long as someone owns keeping the record coherent. The failure is assuming it’ll get reconstructed later. It won’t, not accurately.

Common scribe mistakes

• Transcribing instead of curating. Copying every message produces noise nobody reads. Capture decisions, actions, and observations — the load-bearing moments.
• Dropping timestamps. “We rolled back and it got better” is a story; “rollback 14:18, recovery 14:24” is data. Times are the whole point.
• Getting pulled into the fix. The moment the scribe starts debugging, the record stops. If the scribe has to jump in, hand the pad to someone else first.
• Recording only what worked. The dead ends and ruled-out hypotheses are gold for the postmortem — they show what the team considered and why the incident took as long as it did. Capture the misses too.
• Letting the notes die at resolution. The scribe’s last act is handing a clean timeline to the postmortem owner. That handoff is where the role pays off.

Where AI makes a great scribe’s assistant

This is one of the strongest uses of AI in incident response, precisely because scribing is synthesis, not decision-making. Run a model in the incident channel that produces a running structured summary — confirmed impact, in-flight actions, open decisions — updating as the channel moves. A human scribe (or the IC) then spot-checks and curates it rather than typing every entry from scratch.

The discipline is treating the AI’s output as a draft of reality that a human verifies, never as the authoritative record. It’s synthesizing a chaotic, partial, in-progress picture, so it will occasionally mislabel a hypothesis as a finding or miss a correction. “The summary says we ruled out the CDN — did we, or did we just stop looking?” is the kind of check that keeps it honest. Used that way, it turns the scribe’s job from frantic typing into calm curation, and it means your postmortem timeline is most-written the moment the incident ends. The Incident Response tool can maintain exactly this kind of live current-state view for a human to verify.

Wrapping up

The scribe is the cheapest insurance policy in incident response. One person keeping a clean, timestamped record while everyone else fixes the problem gives the responders a shared picture, gives the commander an at-a-glance status, and hands the postmortem an accurate timeline instead of a reconstruction. Capture decisions and actions, not chatter; keep the timestamps; stay off the keyboard; and let AI carry the synthesis while a human curates. Do that and the postmortem stops being archaeology.

AI-generated timelines and summaries are drafts. A human owns the accuracy of the incident record.

Related

• Facilitating the Major Incident Bridge Call Without Chaos
• The Incident Commander Role Explained for Engineering Teams
• How to Write a Blameless Postmortem That People Actually Read