I’ve been refining our team’s major incident process lately, and while we have a solid alerting setup, our runbooks feel a bit inconsistent. They work for standard issues, but when something major blows up, the documentation doesn’t always keep pace with the chaos.
I’m looking for a template that goes beyond just technical steps. Something that helps with:
* Clear, immediate roles (incident commander, communications lead, scribe) and handoffs.
* Integrating external status page updates or stakeholder notifications into the flow.
* A section for logging key decisions and why they were made, not just actions taken.
* A smooth transition into post-mortem mode, capturing fatigue metrics and blameless evidence.
Most templates I find are either too generic or too tied to a specific platform like PagerDuty or Jira. I’d love to see what others are using, especially if you’ve baked in any automation for things like:
* Auto-creating a dedicated Slack channel or Microsoft Teams meeting.
* Pre-populating a timeline document from alert triggers.
* Automated digests sent to management at set intervals.
What’s worked well for your teams? Any specific structure or tooling that made a real difference during a high-pressure incident?
I've been in that exact spot. Our team runs on a templated Notion doc that's been working well for us, and it hits several of your points.
It starts with a clear "Immediate Actions" section at the top that explicitly names the Incident Commander, Comms Lead, and Scribe. We have a policy that the first person to declare the incident grabs the template and assigns those roles immediately, even if it's just a placeholder. It really cuts down on the initial chaos.
We also have a dedicated "Decision Log" table right below the timeline. It's just two columns: "Decision/Rationale" and "Who/When." Forcing that separation from the action log has been invaluable for post-mortems. It keeps the "why" front and center and helps prevent hindsight bias later on.
For the automation you mentioned around Slack channels and digests, we actually use a few simple Zapier flows hooked into our incident declaration form. It's not perfect, but it handles the channel creation and first status update, which gets everyone into the right place faster. Maybe I can share a redacted version of the template if you're interested?
Keep it constructive.
Totally get the need for something that survives the chaos. Our team uses a Google Docs template that's similar to what user1079 described, but we've added a few living sections that might help.
For the automation you asked about, we use a Zapier hook from our alerting system. It auto-creates the doc, pre-fills a timeline table with the initial alert details, and posts the doc link into a dedicated Slack channel it also creates. It even sets up a quick "war room" Zoom meeting. The key was keeping the automation light so it doesn't break if one service is down.
My biggest piece of advice? Build the **fatigue check** into the template itself. We have a table at the 45-minute mark that the Incident Commander is prompted to fill: just a simple "Energy level (1-5)" and "Should we rotate a role?" for each key person. It forces a pause and captures that context before the post-mortem, when everyone forgets how fried they actually were.
Your emphasis on capturing the *why* behind decisions is the critical piece most templates miss. A decision log should be structured to resist post-hoc justification. We mandate that every entry includes the known information at the time, the considered options, and the selected option with its reasoning. This creates an artifact that's invaluable for both training and blameless analysis.
Regarding automation, our most effective integration was a simple script triggered by the incident declaration. It doesn't auto-create documents, as that can fail, but it *does* auto-populate a pre-existing, blank template with:
* Alert metadata and timestamp.
* A dedicated, persistent war room link (Slack/Teams).
* Pre-filled, rotating role assignments pulled from a roster.
This balances automation with reliability; the template is a static resource, but the data injection saves crucial minutes. The fatigue metric you mentioned is often better as a scheduled, automated prompt to the incident commander's chat client at 30-minute intervals, rather than a static table.
prove it with data