Skip to content

Post-mortem Drafter

Example prompt: "When a PagerDuty incident is resolved, pull the incident timeline, any GitHub deploys from that day, and the Slack thread from #incidents, then draft a post-mortem in our Notion post-mortems database."

How to automate post-mortem drafting with GloriaMundo

The Problem

After an incident is resolved, the team is expected to write a post-mortem within a day or two while the details are still fresh. In practice, the on-call engineer has to manually reconstruct a timeline from PagerDuty alerts, scroll through a long Slack thread to piece together who did what, check GitHub for the deploy that may have caused the issue, and then write it all up in a consistent format. This takes 1-2 hours, and because it feels like paperwork after the crisis is over, it often gets deprioritised or written so late that key details are forgotten.

How GloriaMundo Solves It

We build a workflow triggered when a PagerDuty incident moves to "resolved" status. An integration step fetches the full incident timeline from PagerDuty — when it was triggered, acknowledged, and resolved, plus any notes added during the response. A second integration step retrieves the Slack thread associated with the incident channel, capturing the real-time discussion. A third integration step pulls recent deployments from GitHub around the time the incident started, so the post-mortem includes what changed. An LLM step takes all of this raw data and drafts a structured post-mortem following your template — summary, timeline, root cause hypothesis, what went well, what to improve, and action items. Finally, an integration step creates a new page in your Notion post-mortems database with the draft. Glass Box preview lets you review the assembled timeline and the draft before it is saved, so you can catch any misattributions or missing context.

Example Workflow Steps

  1. Trigger (webhook): Fires when a PagerDuty incident status changes to "resolved".
  2. Step 1 (integration): Fetch the incident timeline from PagerDuty — trigger time, acknowledgement, escalations, resolution, and responder notes.
  3. Step 2 (integration): Retrieve the Slack thread from the incident channel, capturing messages, reactions, and timestamps.
  4. Step 3 (integration): Pull GitHub deployments and merged PRs from the 24 hours before the incident started.
  5. Step 4 (LLM): Draft a structured post-mortem document — incident summary, reconstructed timeline, likely contributing factors, what went well, areas for improvement, and proposed action items.
  6. Step 5 (integration): Create a new page in the Notion post-mortems database with the draft, tagged with the service name and severity.

Integrations Used

  • PagerDuty — incident timeline, severity, and responder notes
  • Slack — real-time discussion thread from the incident response
  • GitHub — recent deployments and merged PRs that may have contributed
  • Notion — destination for the structured post-mortem document

Who This Is For

SRE teams, engineering managers, and on-call engineers at organisations that require post-incident reviews but struggle to write them consistently and promptly.

Time & Cost Saved

Writing a post-mortem from scratch typically takes 1-2 hours of gathering data and writing. This workflow assembles the raw material and produces a first draft in under a minute. The engineer still needs to review and refine it — particularly the root cause analysis and action items — but the bulk of the data gathering and formatting is handled. For a team running 4-6 incidents per month, that is roughly 4-8 hours saved. The workflow uses a handful of integration and LLM steps per run.