📝 The AI Incident Scribe: A Live Timeline That Survives Handoffs

Three hours into a grinding SEV2, the responder who’d been driving had to hand off — kids, sleep, the limits of being human. The next engineer joined the channel cold and asked the question that makes every long incident groan: “So… can someone catch me up?” Cue ten minutes of the exhausted outgoing responder re-typing what they’d already lived through, badly, while the incident kept burning. That handoff tax is a real and recurring chunk of MTTR on any incident that outlasts a single person’s focus, and it’s almost entirely avoidable.

The fix is a live incident timeline that’s always current — so a handoff is “read the timeline,” not “interrogate the tired person.” Keeping that timeline by hand never works, because the person best placed to write it is the person too busy fixing things to write it. That’s the gap an AI scribe fills.

Why handoffs leak so much

The context of an active incident lives in three fragile places: the responder’s head, a scroll of chat messages, and a scattering of command outputs. Handoff means transferring the first one — the head — which is exactly the part that doesn’t survive. The chat scroll contains the story but in raw, unsorted form: 200 messages where 30 matter, interleaved with side chatter and dead-end guesses. A new responder reading the raw scroll cold is slow; the outgoing responder summarizing from memory is lossy. Across the MTTR funnel, this is the phase where information decays rather than where it’s gathered.

An AI scribe turns the channel into a timeline

The scribe’s job is narrow and well-suited to AI: continuously read the incident channel and command outputs, and maintain a structured timeline of what’s known, what’s been tried, and what’s open. It’s summarization and state-tracking, not judgment. I run it as a bot in the incident channel that updates a pinned timeline message.

The prompt that drives it is about discipline, not cleverness:

You are the scribe for an active incident. From the channel messages and pasted command outputs, maintain a running timeline with these sections: Confirmed facts (with the evidence/timestamp), Actions taken (what + by whom + result), Ruled out (hypotheses killed + how), and Open threads (unresolved questions, who owns each). Update incrementally; never invent facts not present in the channel. Attribute every fact to its source message or command output. Keep it under 400 words. Mark anything stated as speculation in the channel as speculative in the timeline.

The pinned timeline reads like this at the handoff moment:

Confirmed facts: 5xx on payments began 01:52, correlates with v2.41.0 deploy (kubectl rollout history, 02:04). Scoped to us-east-1 (region query, 02:06). Actions taken: Rolled back to v2.40.3 at 02:31 (jjoyner) — error rate dropped but did not fully clear. Flushed CDN cache 02:44 (jjoyner) — no change. Ruled out: DB connection exhaustion (pg_stat_activity well under cap, 02:11). Upstream auth (auth latency nominal, 02:14). Open threads: Why didn’t rollback fully clear errors? (unowned). Is there a poisoned cache layer below the CDN? (unowned).

A new responder reads that in ninety seconds and is genuinely caught up — including the crucial “rollback didn’t fully fix it,” which is the kind of detail that gets dropped in a verbal handoff.

Keep the human attributing and correcting

The scribe is a stenographer, not a witness. Its facts are only as good as the channel, and channels contain wrong guesses stated confidently. That’s why the prompt forces attribution and speculation marking — so the timeline distinguishes “confirmed by query” from “someone thought.” When I read the timeline, the attribution lets me re-verify anything load-bearing:

# Re-confirm a "fact" the scribe recorded before I act on it at handoff
kubectl rollout history deploy/payments -n payments | grep 2.41.0

If the scribe recorded “scoped to us-east-1” and I’m about to make a decision that depends on it, I re-run the region query rather than trust the summary. The scribe accelerates ramp-up; it doesn’t replace verification of anything I’m about to act on.

The other human duty: correcting the record in-channel. If the scribe mis-summarizes, you fix it by stating the correction in the channel (“correction: rollback was to 2.40.3 not 2.40.1”), and the scribe folds it in. You never edit the timeline to say something the channel doesn’t support — that’s how you keep it trustworthy.

The same timeline pays off three times

A well-maintained live timeline isn’t just a handoff tool. It pays off at three points:

• At handoff: the new responder ramps in minutes. This is the MTTR win during the incident.
• At resolution: the “ruled out” and “actions taken” sections are your verification context — you can see whether the thing that finally worked addressed an open thread or just masked it.
• At the retro: you already have an attributed, timestamped record instead of reconstructing one from a cold chat scroll days later. The retro happens on facts, not fading memory.

A few practices keep the scribe honest:

• Pin it and keep it short. A 400-word living document gets read; a 4,000-word transcript does not. Brevity is what makes it a handoff tool instead of just more scroll.
• Separate confirmed from speculative, visibly. The whole value is letting a fresh responder trust the confirmed section. Blur that line and they have to re-verify everything, and you’ve saved nothing.
• Don’t let it propose actions. The scribe records what happened; deciding what happens next is the responder’s job. Keep those roles clean so nobody mistakes the timeline for a recommendation.

You can feel out the format on the free incident assistant: paste a messy chat scroll and ask for the structured, attributed timeline, then imagine handing that to a cold responder versus handing them the raw scroll. The prompt library has the scribe prompt with the attribution and speculation-marking rules ready to drop into a channel bot.

Long incidents outlast individual humans — that’s not a failure, it’s biology. The failure is letting each handoff cost ten minutes of re-explanation and a lost detail that reopens the incident. An AI scribe keeps the story current so the baton passes cleanly. The machine writes it down; the humans verify it and decide what’s next.