Turn a Raw Incident Slack Export into a Publishable Postmortem in One Prompt Session

The task

You're the on-call who caught the pager last night. The fire's out, sleep was short, and now there's a P1 postmortem due in 72 hours. The incident channel has 400 messages of paste-storms, screenshots, and half-finished thoughts — and you need to turn it into a document that a director will read and an SRE will action.

Before AI

The manual flow is: scroll the channel top-to-bottom, copy the "important" lines into a doc, reconstruct a timeline with UTC timestamps, guess at what everyone meant by "the thing broke," draft a summary, argue with yourself about wording that sounds blameful, then reformat into whatever template your team uses. On a busy incident that's a solid two hours before anyone else has reviewed a word of it.

The postmortem template most teams borrow from is Atlassian's incident postmortem guide — write a summary of the incident in a few sentences, including what happened, why, the severity of the incident and how long the impact lasted. Straightforward on paper, tedious in practice.

The workflow

The three prompts below are meant to be pasted into a single Claude/ChatGPT session in order. Prompt 1 gets the raw Slack export appended to it. Prompts 2 and 3 operate on whatever the previous step produced.

1. Extract a clean timeline from the raw channel dump

Slack exports are messy: bot messages, threaded replies flattened out, emoji-only reactions, people typing "wait" and then "nvm." You want the model to filter aggressively and normalize timestamps before it does anything else.

You are an SRE assistant helping draft an incident postmortem. Below is a raw export of messages from a Slack incident channel. Your job in THIS step only is to produce a clean, chronological timeline of substantive events.

Rules:
- Convert all timestamps to UTC in HH:MM format. If the export uses local time, assume US/Pacific and convert (subtract nothing if already UTC-labeled).
- Include only events that materially advanced the incident: first detection, alerts firing, hypotheses tested, actions taken (deploys, rollbacks, config changes, restarts), customer impact observations, and resolution confirmation.
- Drop chit-chat, emoji reactions, "thanks", "ack", pager acks, and duplicate reports of the same symptom.
- Preserve the actor's handle (e.g., @alex) but do NOT editorialize about their actions.
- Format as a markdown table with columns: Time (UTC) | Actor | Event.
- At the top, output three lines: DETECTED_AT, MITIGATED_AT, RESOLVED_AT (best guesses from the log, UTC).

Do not draft any other section yet. Timeline only.

Raw Slack export follows:
---

#incident-2094 — checkout-api elevated 5xx

[2026-07-12 14:03 PDT] pagerduty-bot: 🚨 SEV? — checkout-api p99 latency > 3s, error rate 12% (threshold 2%). Runbook: https://wiki.example.com/rb/checkout-5xx
[2026-07-12 14:03 PDT] @jordan: acking
[2026-07-12 14:04 PDT] @jordan: on it, opening channel
[2026-07-12 14:05 PDT] @jordan: /incident declare sev2 checkout-api elevated 5xx
[2026-07-12 14:06 PDT] @priya: looking at dashboards, seeing 5xx spike started ~13:58 PDT
[2026-07-12 14:07 PDT] @priya: it's coming from the /cart/checkout endpoint specifically
[2026-07-12 14:08 PDT] @jordan: any recent deploys?
[2026-07-12 14:09 PDT] @sam: yes, checkout-api v4.812 rolled out at 13:52 PDT
[2026-07-12 14:09 PDT] @sam: 👀
[2026-07-12 14:10 PDT] @priya: correlation looks strong, 5xx started 6 min after deploy
[2026-07-12 14:11 PDT] @jordan: let's roll back. @sam can you drive?
[2026-07-12 14:11 PDT] @sam: on it
[2026-07-12 14:12 PDT] @dana: cs is getting tickets, ~15 so far, users can't complete checkout
[2026-07-12 14:14 PDT] @sam: rollback to v4.811 initiated
[2026-07-12 14:16 PDT] @sam: rollback complete, watching metrics
[2026-07-12 14:17 PDT] @priya: 5xx dropping
[2026-07-12 14:18 PDT] @priya: back to baseline (~0.3%)
[2026-07-12 14:19 PDT] @jordan: 🎉
[2026-07-12 14:20 PDT] @dana: cs confirms new tickets stopped
[2026-07-12 14:22 PDT] @jordan: staying open for 20 min to confirm stable
[2026-07-12 14:35 PDT] @priya: dug into v4.812 diff — new retry logic in the payments-client wrapper, looks like it's retrying on 400s which the payment provider rate-limits, causing a cascade
[2026-07-12 14:36 PDT] @priya: the retry doesn't respect Retry-After either
[2026-07-12 14:42 PDT] @jordan: ok calling it. resolving. will schedule PM for thursday.
[2026-07-12 14:42 PDT] @jordan: /incident resolve
[2026-07-12 14:43 PDT] @sam: thanks all
[2026-07-12 14:43 PDT] @priya: 👍

2. Draft the postmortem body from the timeline

Now that the timeline is normalized, ask for the narrative sections. Keep the blameless framing explicit in the prompt — models will default to naming individuals as causes if you don't tell them not to. One of the foundational rules for 5 whys is never to identify a person or people as the root cause.

Using the timeline you just produced, draft the following postmortem sections. Follow the rules strictly.

Sections to produce, in this order:
1. **Summary** — 3-4 sentences. What happened, user impact, duration, how it was mitigated. Written for a non-engineer director.
2. **Impact** — bulleted: affected service, affected users/requests (estimate from the log), duration of degradation from DETECTED_AT to MITIGATED_AT, business signals mentioned (e.g., support tickets).
3. **Root cause** — apply the 5 Whys. Frame every "why" as a systems or process question, never a person. If the log doesn't support a full 5 levels, stop honestly at the level the evidence reaches and label the rest "unknown — investigate."
4. **Contributing factors** — 2-4 systemic factors (missing tests, gaps in review, alerting blind spots, etc.), inferred conservatively from what the log shows.
5. **What went well** — 2-3 concrete things the responders did effectively. Cite timeline entries.
6. **What went poorly** — 2-3 concrete gaps. Systems, not people.

Blameless language rules:
- Never write "X caused the incident" or "X failed to." Write "the deploy introduced…" or "the review process did not catch…"
- No speculation beyond what the timeline supports. If something is unclear, say "unclear from available evidence."

3. Generate action items and format the whole thing for publishing

Action items are where most postmortems die — vague verbs, no owner, no date. Force the model to be specific.

Produce the final two sections and then assemble everything into a single publishable document.

**Action items** — a markdown table with columns: ID | Action | Type (Prevent / Detect / Mitigate) | Suggested Owner Role | Suggested Priority (P0/P1/P2).
- Each action must start with a concrete verb (Add, Change, Remove, Document, Instrument).
- No action items about "being more careful" or "improving communication."
- Suggest role (e.g., "checkout-api team", "SRE") not a person's name.
- Include at least one Detect item (monitoring/alerting gap) and one Prevent item.

**Lessons learned** — 2-4 sentences. What the org should generalize from this incident to other systems.

Then output the FINAL DOCUMENT with this exact structure and headings, ready to paste into Confluence:

# Postmortem: [service] [one-line description] — YYYY-MM-DD

**Status:** Draft • **Severity:** [from timeline] • **Author:** [leave as TODO]
**Detected:** [UTC] • **Mitigated:** [UTC] • **Resolved:** [UTC]

## Summary
## Impact
## Timeline
## Root cause
## Contributing factors
## What went well
## What went poorly
## Action items
## Lessons learned

At the very end, add a "Reviewer checklist" with 4 checkbox items the human author should verify before publishing (names anonymized, customer impact numbers confirmed, action item owners assigned, blameless language check).

Gotchas

• Timezone conversion is where the model most often lies. If your Slack export has mixed timezones (bots in UTC, humans in local), spot-check two or three converted timestamps against the raw log before you trust the timeline.
• Impact numbers get invented. The model will happily write "affected approximately 8% of checkout traffic" when the log only says "elevated 5xx." Delete any number the log doesn't actually contain and replace with "TODO — pull from metrics."
• 5 Whys can hallucinate causes. If the log doesn't explain why the bad code got shipped, the model may invent a review process gap. The prompt tells it to stop at "unknown" — enforce that when you edit.
• Action items skew toward "add more monitoring." That's the model's comfort zone. Push back and add at least one code-level or process-level item yourself.
• Blameless framing is easy to violate in the "What went poorly" section. Re-read it. If a sentence names a person or a team as the cause rather than a contributor within a system, rewrite it. The Atlassian 5 Whys guide is worth a re-skim if you're unsure.
• Long channels (1000+ messages) exceed context on smaller models. Chunk by hour if needed, produce timelines per chunk, then merge in a final pass.

Time saved

Rough estimate: 60-90 minutes per incident. The manual work this replaces is the mechanical part — scrolling, timestamp conversion, first-draft narrative, template formatting. What you still owe the document: verifying impact numbers against your metrics dashboard, confirming the root cause with whoever wrote the offending code, and assigning real owners and dates to action items. That's maybe 30 minutes of focused work instead of a lost afternoon.

If your team runs one P1/P2 postmortem a month, that's ~12 hours a year back per on-call rotation.

What we got when we ran it

We executed every prompt above, in order, against the sample input (model: claude-sonnet-4-6). Outputs below are real and unedited apart from length truncation.

Step 1 output

DETECTED_AT: 21:03 UTC MITIGATED_AT: 21:18 UTC RESOLVED_AT: 21:42 UTC | Time (UTC) | Actor | Event | |------------|-------|-------| | 21:03 | pagerduty-bot | Alert fired: checkout-api p99 latency > 3 s and error rate at 12% (threshold 2%) | | 21:05 | @jordan | Incident declared SEV2: checkout-api elevated 5xx | | 21:06 | @priya | Dashboard review: 5xx spike observed with onset traced back to ~21:58 UTC | | 21:07 | @priya | Identified /cart/checkout endpoint as the source of 5xx errors | | 21:09 | @sam | Confirmed checkout-api v4.812 deployed at 21:52 UTC | | 21:10 | @priya | Noted strong temporal correlation: 5xx began ~6 minutes after v4.812 deploy | | 21:11 | @jordan | Decision made to roll back to v4.811 | | 21:12 | @dana | Customer Support receiving ~15 tickets; users unable to complete checkout | | 21:14 | @sam | Rollback to v4.811 initiated | | 21:16 | @sam | Rollback complete; monitoring metrics | | 21:17 | @priya | 5xx error rate observed dropping | | 21:18 | @priya | Error rate returned to baseline (~0.3%) | | 21:20 | @dana | Customer Support confirmed inbound tickets have stopped | | 21:22 | @jordan | Incident kept open for 20-minute stability watch | | 21:35 | @priya | Root cause identified in v4.812 diff: new retry logic in payments-client wrapper retries on HTTP 400 responses, triggering payment provider rate-limiting and causing a cascade | | 21:36 | @priya | Additional finding:

…output truncated at 250 words.

Step 2 output

# Postmortem — Incident 2094: checkout-api Elevated 5xx Date: 2026-07-12 | Severity: SEV2 | Status: Resolved --- ## 1. Summary On 2026-07-12, the checkout-api experienced an elevated error rate beginning at approximately 21:58 UTC, peaking at 12% 5xx responses against a 2% threshold, and affecting users' ability to complete purchases. The degradation was traced to checkout-api v4.812, which introduced retry logic in the payments-client wrapper that triggered rate-limiting by the payment provider and cascaded into elevated failures on the /cart/checkout endpoint. Mitigation was achieved at 21:18 UTC by rolling back to v4.811, approximately 15 minutes after first detection. The incident was fully resolved and declared closed at 21:42 UTC following a stability watch period. --- ## 2. Impact - Affected service: checkout-api — /cart/checkout endpoint - Error rate at peak: 12% (5xx responses; normal baseline ~0.3%) - Estimated user impact: Unclear from available evidence — precise request volume not logged; at least ~15 customer support tickets filed, indicating a meaningful number of users unable to complete checkout - Duration of degradation: ~20 minutes (21:58 UTC onset → 21:18 UTC mitigation; alert-to-mitigation window ~15 minutes from 21:03 UTC) - Business signals: - ~15 inbound customer support tickets opened during the incident - Customer Support confirmed ticket flow ceased following rollback (21:20 UTC) --- ## 3. Root Cause — 5 Whys Why 1: Why were users unable to complete checkout? The checkout-api /cart/checkout endpoint returned 5xx errors at a rate of 12%, well above the 2% threshold. **Why 2: Why did the

…output truncated at 250 words.

Step 3 output

Action Items | ID | Action | Type | Suggested Owner Role | Suggested Priority | |----|--------|------|----------------------|--------------------| | AI-01 | Add integration tests covering payment provider HTTP 400 and rate-limit response paths against the payments-client wrapper retry logic | Prevent | checkout-api team | P0 | | AI-02 | Add a documented retry policy contract to the payments-client wrapper specifying which HTTP status codes are safe to retry, enforced via code review checklist | Prevent | checkout-api team | P0 | | AI-03 | Instrument the payments-client wrapper to emit a metric for retry attempts per status code, and alert when retry rate on 4xx responses exceeds a defined threshold | Detect | SRE | P0 | | AI-04 | Change the payments-client retry logic to read and respect upstream `Retry-After` headers before any re-attempt | Prevent | checkout-api team | P0 | | AI-05 | Instrument a deploy-time canary gate on the checkout-api pipeline that automatically halts and rolls back if the 5xx error rate exceeds threshold within N minutes of rollout | Detect | SRE | P1 | | AI-06 | Change the checkout-api deploy pipeline to use a progressive (staged) rollout strategy (e.g., 1% → 10% → 100%) with automated promotion criteria | Mitigate | SRE / Platform | P1 | | AI-07 | Document the payment provider's rate-limiting behavior and error-code contract in the internal runbook, linked from the checkout-api deploy checklist | Prevent | checkout-api team | P2 | --- ## Lessons Learned Integrations

…output truncated at 250 words.