role · on-call

On-call

On-call is the cycle's last and first reader. They are awake when reality answers. Their job is to keep the timeline honest, to communicate to the people watching, and to hand the postmortem something it can actually use.

What good looks like

A competent on-call shift produces three artefacts every cycle they are summoned:

1. A timeline — minute-by-minute, written during, that the postmortem can read without rewriting.
2. A comms thread — what was told to whom and when. Engineering thread. Client thread if needed. No surprises in the morning.
3. A runbook entry or change — every shift either uses a runbook (and notes the friction) or writes one. No two pages on the same scenario.

An on-call shift that produces these has the operation chain working. A shift that skips the timeline leaves the postmortem inventing history; one that skips the runbook update locks the knowledge in one person.

The on-call's stance

On-call is responsible for	On-call is not responsible for
The timeline being written during, not after	Solving the root cause alone
The comms thread to engineering, leadership, client	Being the only person on the bridge
Following the runbook or noting why they didn't	Rewriting the architecture at 2am
The first 48-hour watch on every cycle's first release	The full release decision
Handing the postmortem material it can use	Owning the postmortem's fix

On-call holds the chain by holding the moment the system was under stress and the record of what happened.

Three artefacts to read first

1. Runbooks & Rollback
2. The First 48 Hours
3. Incidents & Postmortems

First 30 days

Day 1–3 — Read the canon

Read As We Build Parts 8, 9 (Runbooks & Rollback, Observability). Read After We Build Parts 1, 4 (First 48 Hours, Incidents & Postmortems).

Output: in three sentences, name the difference between first-contact noise and signal worth following up on.

Day 4–7 — Shadow on-call

Sit on-call alongside the experienced rotation for at least one shift. Do not act. Watch the timeline, watch the comms, watch the runbook usage.

Output: a one-page note on what surprised you about the shift.

Day 8–14 — Walk every runbook

Open every runbook in the team's library. For each: when was it last used, does it still work, who would understand it cold.

Output: a list of runbooks to rewrite, kill, or merge.

Day 15–18 — Hold your first first-48h watch

When the next release goes out, you drive the first 48 hours. Watch dashboards. Write the timeline of anything that moved.

Output: a first-48h note with at least one observed signal and at least one piece of first-contact noise correctly distinguished.

Day 19–25 — Handle a real incident (or simulate one)

When an incident fires, you run the bridge. Timeline. Comms. Runbook. If no real incident, hold a game day with the team.

Output: signed timeline, comms log, and a runbook update.

Day 26–30 — Drive a postmortem

Hold the postmortem for the incident or game day. Walk the timeline. Identify the chain level. Land one change — owned, dated, testable.

Output: committed postmortem with a chain-level fix that is not just more monitoring.

Deepening — self-rate yourself

Timeline craft

• My timeline reads cleanly without my voice in the room.
• I never write the timeline after the fact.
• I have killed entries that were noise so the signal survives.

Comms craft

• Engineering, leadership, and client each have their own thread; none surprised in the morning.
• The first message is short and orienting, not heroic.
• I have de-escalated a thread without it being a personal moment.

Runbook discipline

• I either use a runbook or write one — every shift.
• My runbooks read at 2am, in adrenaline, in 30 seconds.
• I have killed runbooks that were no longer true.

Incident craft

• I can hold a bridge for two hours without the team's clarity decaying.
• I know when to declare resolved and when to keep watching.
• The shift handoff at the end of an incident is clean.

Postmortem hand-off

• I hand the postmortem a timeline it can read.
• I do not own the postmortem's chain-level fix, but I can name the level honestly.
• I have raised a chain level higher than my own role without it being a personal moment.

Stuck if…

…the postmortem keeps reconstructing the timeline

The timeline wasn't written during. Re-read Incidents & Postmortems. The during-write is the discipline that protects the after-write.

…the same incident type keeps firing

The fix is not at the level it was made at. Re-read Bugs and Their Roots. More monitoring is rarely the right level for a recurring incident.

…leadership hears about the incident from the client

Comms broke. The client thread either wasn't opened or wasn't honest. The no-surprises rule held only if leadership was hearing it from on-call first.

…the runbook didn't work

That is the runbook's failure, not yours. Write down what happened and rewrite the runbook before the next shift. Locking the knowledge in your head is the corpus's failure mode.

…you finished the shift exhausted with no record

The shift was unstructured. Re-read The First 48 Hours. Take notes during, even on quiet shifts; the discipline holds when nothing happens.

…an incident drifted past hour two with no de-escalation plan

Stop. Either hand off or declare a longer incident with a structured rotation. Heroic shifts produce shallow postmortems.

See also

• Skill path — On-call foundations
• Canon — As We Build · After We Build
• Practice — First 48 hours watch · Release gate · Postmortem
• Templates — Runbook · Release brief · Postmortem
• Checklists — First 48 hours · agenda · Release gate · Postmortem
• Clinics — A flag that never got cleaned up · A postmortem that produced a feeling · A runbook that doesn't run
• Areas — 8 · Pipeline & Operations · 10 · Post-Release & Learning