Operating in Production: On-Call, Incident Command, and Reporting Clocks Module 3 · Command

Hand Over the Command

Last reviewed · content updated

Intermediate

What you'll learn

~14 min
  • Perform a spoken incident-command handoff and log it in the record's handoff sub-table - outgoing, incoming, acknowledgment time, open items
  • Treat the operational period as a fatigue budget the commander manages, not just a shift length
  • State what a long-running incident costs a team, by pointer, without re-deriving the case

Before the detail — Decision: never let the commander seat change hands without a spoken statement and a confirmed answer. Outcome: an incident that survives a shift change with no gap in who is deciding, and a commander who calls for relief before the team is spent. Artifact: a handoff checklist, plus the handoff logged in the record’s own handoff sub-table - outgoing, incoming, acknowledgment time, and the open items actually handed over. Status of what follows: common baseline.

Prompt first: script the handoff, then log it

I am about to hand off incident command. Here is the current state
[paste: severity, what's mitigated versus still degraded, any open
decisions, any clock running and its owner] and the name of who is
taking over.
Draft the SPOKEN handoff script I will read on the call: current
state, what has been tried, what is still open, any clock running and
who owns it, and a closing line that is a QUESTION the incoming
commander must answer out loud - not a statement I can just finish
talking over.
Then draft the ONE row this produces for the record's handoff
sub-table: outgoing name, incoming name, the timestamp of the
acknowledgment (not the timestamp I started talking), and the open
items actually confirmed back - not just the ones I mentioned.

The handoff is spoken, and it is acknowledged

Google IMAG scripts the handoff: the outgoing commander states “You’re now the incident commander, okay?” and “should not leave the call until receiving firm acknowledgment.” The question mark is the design. A statement can be talked over, missed on a bad connection, or half-heard by someone who has been up since midnight; a question forces a spoken answer, and the outgoing commander stays on the line until they get one.

That acknowledgment belongs in the record as its own artifact, not a note in someone’s memory. The committed NON-PRODUCTION tabletop’s own handoff inject scripts the identical line - the outgoing incident commander, s.amari, tells the incoming commander, d.reyes, “You’re now the incident commander, okay?” - after s.amari has already taken the commander seat at declaration, not before. From scripts/t8-substrate, running python3 tabletop/tabletop.py --auto --emit-decisions /tmp/incident-record.INC-2026-052.md writes a dedicated sub-table into the incident record’s section 4, separate from the decisions table, with times in UTC:

OutgoingIncomingAcknowledged at (UTC)Open items handed over
s.amarid.reyes2026-11-03T07:20:00Zpaste-site link preserved; production match not yet sampled; p.velasquez paged as clock owner at 02:15; s.amari confirmed all three before leaving

(This is the INC-2026-052 tabletop exercise - a different scenario from 3.2’s INC-2026-041 mitigation call, and the rehearsal is where this specific discipline gets tested.) incident/validate.py checks this table on three counts: incoming may never equal outgoing - a handoff transfers the seat to somebody else; the open-items list may never be empty - a handoff with nothing in it did not happen, though an item list that starts with unconfirmed - is accepted as a WARN, because that is a valid record of a bad handoff, and recording it is the finding; and the acknowledgment instant may never fall before the record’s own declared transition - a commander seat cannot be handed over before anyone has taken it. The read-back option is what fills the open-items column with a real list; choosing the faster “got it, go” option instead emits the unconfirmed - row. One handoff row, no blanks: an IC handoff with no acknowledgment on record did not happen.

The operational period is a fatigue budget

NIMS (the National Incident Management System — FEMA’s federal framework for coordinating a response)‘s 2017 edition says an operational period is “generally 12 to 24 hours.” Separately, Google recommends limiting on-call shifts to 12 hours. House practice here is to align commander relief to the shorter staffed shift; the NIMS excerpt itself does not attribute its range to fatigue.

The commander’s version of that cap is the seat itself, not just the shift under it: on a long incident, command should change hands on roughly the same clock the rota already uses for responders, and for the same reason. A commander who stays in the seat past their own operational period is making decisions on the same degraded judgment 2.3’s cap was built to keep off the response entirely — the cap just moved from the responder rota to the seat that decides what the responders do next.

Treating the operational period as a scheduling detail instead of a fatigue budget is a risk the commander owns precisely because nobody else in the room is positioned to notice it happening to them.

What a long incident does to a team

5.4’s forty-eight-hour case is the worked example; this lesson uses only the pointer. The handoff and operational-period disciplines must work across successive shifts, without assuming that one named team worked continuously or without sleep.

A commander who assumes every incident closes in one operational period has no plan for the one that doesn’t — and the plan is exactly the handoff checklist this lesson already built, run once more than expected.

Stop and escalate when an operational period is about to close with no relieving commander named. This reopens 1.3’s coverage decision. If a binding floor exists, activate funded backup or contracted coverage, or route a written modification to contract authority; only where no binding floor exists may the named risk acceptor accept degraded coverage.

KNOWLEDGE CHECK

An outgoing commander says on the call, 'You've got it,' and immediately drops off to sleep. The incoming commander was mid-sentence on another line and didn't clearly hear it. What does this lesson say went wrong?

Key takeaway

The commander seat changes hands on a spoken question, not an announcement, and the outgoing commander stays on the line until they hear a firm answer — then that acknowledgment goes into the record’s own handoff sub-table, not the general timeline. The operational period is the seat’s version of the rota’s shift cap: a fatigue budget, not a scheduling convenience, and the commander who ignores it is deciding on judgment nobody in the room is positioned to check. 5.4’s forty-eight-hour case is what happens when an incident outlasts several operational periods in a row. The next lesson turns from the commander’s own seat to the assistant now sitting beside it.

LEADERSHIP DECISION require a spoken, acknowledged handoff and a
bounded operational period for the commander
seat on every incident that runs past one shift
PRACTITIONER ACTION script the handoff as a question, wait for the
answer, log outgoing, incoming, acknowledgment
time, and open items in the record's handoff
sub-table, and call for relief before the
operational period closes
SUCCESS MEASURE zero incidents where two people each believed
the other still held the commander seat - a gap
measured in minutes, once found, twice prevented
Search lessons