The Decision Log and Handoff Discipline During Incident Rotation

In long-running incidents, the most overlooked risk isn’t the technical fault itself — it’s context loss. Teams change, fatigue piles on, and people forget which hypothesis got ruled out and why. The new team retries the same experiments, can’t see why a risky decision was made the way it was, and the incident drags on longer than it has to.

That’s why on big incidents you don’t just need a status update — you need a decision log. The quality of a handoff often determines safety and communication just as much as it determines MTTR.

1) What is a decision log?

A decision log is part of the incident timeline, but it’s more selective. It carries:

• Which hypothesis got considered?
• What evidence turned up?
• What action was taken?
• Why was it taken?
• What risk was accepted?

With this record, the new team gets to see why we went down that path instead of just a list of “things we did.”

2) When do you need a handoff?

A formal handoff is mandatory in scenarios like these:

• The incident is rolling into a shift change
• The IC or tech lead is hitting their fatigue threshold
• A team from a different specialty is taking over
• The incident has moved into a “stable but not resolved” state

A common mistake here is letting the handoff drift along freely in Slack. Random messages show you the past but don’t carry the decision logic.

3) A solid handoff template

I’ve found these five sections to be really useful:

1. Current impact: which users, which services?
2. Working hypothesis: what’s the strongest explanation right now?
3. Evidence: signals that support that hypothesis
4. Things tried: changes that were attempted and what came of them
5. Boundaries: risky actions that should not be taken

This five-pointer drops the new team straight onto the decision surface.

4) What do I specifically write into the decision log?

• If we didn’t roll back, why?
• What message went out to customers?
• Which data source did we decide we couldn’t trust?
• Which actions can only be taken with IC approval?

Because as an incident drags on, teams stop forgetting the technical details and start forgetting the decision context.

5) Classic mistakes during handover

• Using vague phrases like “we looked at the logs”
• Writing only the command instead of the result of the experiment
• Leaving a risky change as a verbal note
• Not making it clear who’s in charge of decisions after the handoff

At the end of every handoff, there has to be a single, explicit ownership statement: “From this point on, coordination is on X, and the technical recommendation sits with Y.”

6) It’s a habit, not a tool

You can keep the decision log in a wiki, in your incident tool, or in a shared doc. The tool is secondary. What actually moves the needle is the habit:

• A short note after every important decision
• A status summary every 10–15 minutes
• A final risk list before every handoff

That cadence keeps the system calm when an incident drags on. Instead of relying on human memory, it makes the decisions visible.

Conclusion

In long-running incidents, what determines quality isn’t just good engineering — it’s good handover discipline. With a decision log and a clean handoff flow, the new team doesn’t keep slamming into the same wall, the risky actions stay visible, and coordination doesn’t fall apart. Professionalism in incident management often comes from “cleaner context handover,” not “more people on the call.”