How to create an incident postmortem from Slack, GitHub, and Linear

Write an incident postmortem by reconstructing a defensible timeline from the systems that already recorded the incident, then labeling every claim by how certain it is. Slack holds the investigation. GitHub holds the code changes. Linear holds the tracked work. Monitoring holds what actually happened to the system. The postmortem connects all four. The difficult work is assembling an evidence trail that survives being questioned six months later.

TL;DR

• The incident record is fragmented by function: Slack has the investigation, GitHub has the code changes, Linear has the tracked work, and monitoring has the observed events.
• The expensive work in a postmortem is reconstructing a defensible timeline, not writing paragraphs.
• Separate the evidence into observed events, human actions, system changes, conclusions, and follow-ups before you write anything.
• Label every cause as suspected, ruled out, confirmed, or contributing, because flattening uncertain Slack discussion into stated fact is how postmortems become wrong.
• Google’s SRE practice treats the postmortem as blameless and centered on systems and process, not on the person who typed the command. Blameless about cause and named about follow-up are compatible, and both are required.
• Procedure defects are the thing postmortems exist to fix. Uptime Institute found that nearly 40% of organizations had a major outage caused by human error over three years, and that 85% of those traced to staff not following procedures or to flaws in the procedures themselves.
• Writing the procedure down pays. Google’s SRE book reports that recording best practices in a playbook ahead of time produces roughly a 3x improvement in MTTR compared with improvising.
• Verify the assembled postmortem before publishing: every timeline entry needs a source link, every deploy needs a SHA, every action item needs a real issue ID with an assignee.
• Falconer can draft a cited, plain-language RCA from connected code and Linear context, a Slack thread it can access, and monitoring evidence you provide. The report becomes searchable after you save it as a Falconer document.

Why is writing an incident postmortem so hard?

The difficulty is not literary. By the time someone sits down to write, the record has degraded:

• Slack timestamps are buried under a thousand messages in the incident channel
• Temporary fixes and permanent fixes are mixed together in the same thread
• The first suspected cause has quietly been promoted to the final cause
• Follow-up work exists across several tickets, some of them already closed
• Nobody remembers exactly when customer impact ended

Each system recorded one incomplete slice of the incident. None of them was responsible for the whole. The person writing the postmortem inherits the job of stitching four partial records into one account that a director, an auditor, or a new engineer can trust.

The reason this is worth doing well shows up in the outage data. Uptime Institute’s 2026 analysis found 57% of respondents saying their most recent major outage cost more than $100,000, and one in five saying it cost more than $1 million. Its earlier analysis found that where human error caused an outage, 85% of cases traced to procedures not being followed or to the procedures themselves being wrong. The corrective action in a postmortem is the repair for exactly that category, which makes the document’s accuracy an operational concern rather than a documentation one.

Blameless as a working standard

Google’s SRE book frames the goal as a blameless postmortem focused on systems and process, and its worked example shows how much of the document is timeline and evidence rather than narrative. The example is a constructed one, for a fictional service, which makes it useful as a template rather than as a case study.

Blamelessness is not the same as anonymity

The two ideas that look contradictory are not. Be blameless about cause and named about follow-up.

Nobody’s name belongs in the root-cause section, because a system that lets one command cause an outage is the finding. Every corrective action needs a name on it, because an unowned action item is how the same incident happens twice. PagerDuty’s postmortem process designates a postmortem owner at the end of the incident call, and Google’s SRE workbook chapter on postmortem culture lists missing ownership as a defect in the document.

What are the five kinds of incident evidence?

Before you write, sort the record into five buckets. Mixing them is what produces a postmortem that reads as confident and turns out to be wrong.

Evidence type	Source of record	What it establishes	Common failure
Observed events	Monitoring, alerts, error rates, customer reports	What the system did and when	Alert time mistaken for incident start
Human actions	Slack, incident channel, on-call notes	What people investigated, mitigated, escalated	Mitigation credited to the wrong change
System changes	GitHub deploys, rollbacks, config changes, merged fixes	What changed in production	Temporary and permanent fixes merged into one line
Conclusions	Postmortem review	Root cause and contributing factors	First hypothesis recorded as final cause
Follow-ups	Linear issues, owners, deadlines	What will prevent recurrence	Actions with no owner or verification step

Machine timestamps beat message timestamps

Sorting first means the timeline gets built from observed events and system changes, which carry machine timestamps, rather than from Slack messages, which carry the timestamp of when someone typed rather than when the thing happened.

How do you reconstruct the timeline?

Start from the systems that timestamp automatically. Alertmanager and your metrics backend give you the detection moment and the shape of the impact window. Traces, metrics, and logs give you the system’s own account of what degraded and when. Deployment records and git log show what shipped during the window, including changes that may not appear in the incident discussion.

What Slack is and is not evidence for

The human record goes on top of that. Slack tells you what people believed at each point, which matters for the detection and response sections, and is exactly the material you should not treat as fact about the system. Our guide on tools that answer questions from Slack using internal docs covers the retrieval side of this.

Where corrective actions live

Linear closes the loop on corrective actions. Falconer incrementally refreshes changed Linear issues and Linear Documents, while projects and related metadata are also refreshed during connector runs. This keeps the latest ingested corrective-action status connected to the incident record. The Linear documentation covers how issues and projects relate.

A useful ordering rule: build the timeline from machine timestamps, then annotate it with what humans knew at each point. Two columns, not one.

What structure should an incident postmortem use?

A useful template has ten sections, in this order:

1. Executive summary
2. Customer impact
3. Detection
4. Timeline
5. Root cause
6. Contributing factors
7. What worked
8. What failed
9. Corrective actions
10. Evidence and citations

The evidence section determines whether readers can verify the account later. PagerDuty’s postmortem process assigns a named owner to the document and treats the review as a scheduled step rather than an optional follow-up.

One triggering change, several conditions

Separate the proximate trigger from contributing conditions without assuming every incident has a single root cause. Dan Luu’s collection of public postmortems shows why simple, single-cause stories often miss important conditions.

How do you handle uncertainty in a postmortem?

Never flatten uncertain discussion into fact. Label every causal claim as one of four things:

• Suspected cause: someone proposed it during the incident and it has not been confirmed or ruled out.
• Ruled-out cause: it was investigated and the evidence excluded it. Record these, because the next responder will suspect the same thing.
• Confirmed cause: the evidence supports it and the reviewer accepted it.
• Contributing factor: it did not trigger the incident, and removing it would have reduced the impact.

The difference between a suspected and a confirmed cause is the same distinction we describe in tracking in-flight versus settled decisions. An open question written as a settled one is a defect in the document, and it propagates: the next team reads a confident sentence and builds on it.

Labels make blamelessness operational

This labeling is also what keeps a postmortem blameless in practice rather than in stated intention. Atlassian’s guidance on blameless postmortems makes the cultural argument; the labels make it operational, because a claim marked “suspected” cannot become an accusation.

How do you verify the postmortem before publishing it?

An assembled timeline can be internally consistent and still wrong. Check five things before the document goes out.

1. Every timeline entry resolves to a source. A permalink to the Slack message, the commit SHA, the alert, or the ticket. An entry with no link is a claim, not evidence.
2. Every deploy in the window is accounted for. Run git log --since --until across the impact window and reconcile it against the timeline. The deploy nobody discussed in the incident channel is the one worth finding.
3. The impact window comes from monitoring, not from the alert. See the failure modes below.
4. Every causal claim carries its label. Suspected, ruled out, confirmed, or contributing. An unlabeled cause reads as confirmed.
5. Every corrective action resolves to a real issue ID with an assignee and a date. “Improve monitoring” with no owner is not an action item.

Run these as a checklist in the review meeting rather than as a pre-read. Disputed evidence is what the meeting is for.

Where does an assembled postmortem go wrong?

Six failure modes, in rough order of how often they bite.

Failure mode	Why it happens	The check
Alert time used as impact start	Alertmanager groups and delays notifications by design, so the page fires after degradation began	Take the impact window from metrics, and record detection separately from onset
The loudest theory becomes the root cause	Whoever wrote most in the channel shaped the record	Label causes by evidence, not by who proposed them
A revert read as the cause	The revert commit sits closest to recovery in the log	Check commit direction and parentage before assigning causality
Timezone and epoch mixing	Slack ts values, UTC monitoring, and local human timestamps in one table	Normalize to UTC and state the offset in the document
The decision is missing	It happened in a huddle or a DM that was never exported	Note the gap in the document instead of inferring the decision
Temporary and permanent fix merged	Both shipped during the window	Two timeline entries, labeled

The first row is the one that quietly corrupts the most postmortems, and it is also the easiest to fix.

Who writes it, and how much can be automated?

Assign one owner for the document and give them the authority to close it. The SRE workbook’s chapter on postmortem culture sets a deliberately weak version against the real postmortem Google wrote for the same 2014 outage, and the difference is mostly rigor about evidence rather than writing skill. The weak version was published four months after the incident. The real one went out four days after it closed.

Speed is part of the standard, not separate from it. PagerDuty schedules the review within three calendar days for a SEV-1 and five business days for a SEV-2, with the document circulated 24 hours ahead and the meeting held to 15 to 30 minutes.

What automates well and what does not

Automation is useful for assembly and dangerous when it turns uncertain evidence into conclusions. Gathering deployments, alerts, merged fixes, and ticket status is mechanical. Deciding the root cause is a judgment call that should stay reviewed.

How Falconer drafts the RCA

Falconer is a context engineering platform that connects code, docs, tasks, and on-demand Slack context. For an incident, it can draft a cited, plain-language RCA from connected GitHub and Linear context, a Slack thread it can access, and monitoring evidence you provide. Save the draft as a Falconer document to make it searchable.

Falconer can create Linear tickets with a title, description, team, optional project and labels, and an assignee when one can be resolved. Its current issue-creation flow does not set due dates, so add deadlines in Linear. For eligible documents with auto-update enabled, a merged pull request can trigger a targeted runbook update or a draft for review. A human should review the final root-cause conclusion.

If you want to test this on a real incident, run it on one you already closed. Draft the timeline from the connected evidence, then compare it with the original postmortem. Look for missing deployments, unsupported causal claims, and differences between when an event happened and when someone reported it. Our guide on writing a self-review, changelog, or meeting prep with AI covers the same assemble-then-review pattern on lower-stakes documents.

How does the postmortem stay useful after it is filed?

A postmortem loses value when people cannot retrieve it in the flow of later work. Someone hits a strange constraint, asks why it exists, and needs the incident that produced it.

That means the postmortem has to be connected to the same knowledge layer as the code, the tickets, and the runbooks it references. Connecting GitHub, Slack, Linear, and Notion into one company brain is what makes an eighteen-month-old incident retrievable by the engineer who needs it, and capturing critical knowledge deliberately is what stops the incident’s lessons from leaving with the responder.

FAQ

Who should be responsible for writing the postmortem after an incident?

Assign a single named owner, usually the incident commander or the responder with the most complete view, and give them a deadline. Clear ownership reduces ambiguity about who must complete the draft and resolve review comments. Falconer can assemble connected evidence and draft the timeline so the owner’s job centers on review and judgment.

Do all incidents require a postmortem, or only the severe ones?

Most teams set a severity threshold plus a few automatic triggers, such as customer-visible impact, data loss, or a repeat of a previous incident. The cost argument against writing more of them is mostly assembly cost, which is the part that automates well.

What is the difference between a root cause and a contributing factor?

A root cause is a change or condition necessary to explain why the incident occurred. A contributing factor increased the likelihood, impact, or recovery time without fully explaining the incident on its own. Write both, label which is which, and allow for incidents with multiple interacting causes.

How do I reconstruct a timeline from a long incident thread?

Build the timeline from machine timestamps first: alerts, metrics, deployments, rollbacks, and merged commits. Then annotate it with what people believed at each point, using Slack as a record of belief rather than a record of system events. Falconer does not index Slack history. In Slack, mention Falcon in the incident thread to draft from that conversation. In Falconer, Slack lookup is limited to the 15 most recent top-level messages in a named public channel, or one public-channel thread link where Falcon is a member. Falconer can combine accessible thread context with connected GitHub and Linear evidence in a cited draft.

Can AI write the entire postmortem without human review?

It should not. Assembling evidence, drafting the timeline, and finding related deployments are mechanical and automate well. Root cause is a reviewed conclusion. Falconer can produce a cited draft, but a human should validate the evidence and accept, revise, or reject each causal claim.

What information should the team collect before the postmortem review meeting?

Collect alerts and metrics covering the impact window, every deployment and rollback in that window, the relevant incident thread or channel export, tickets opened during the incident, and customer-impact data. Build the timeline before the review so the meeting can focus on disputed evidence, causes, and corrective actions.

How do I stop corrective actions from being quietly dropped after the postmortem?

Give each action an owner, a ticket, a deadline, and a verification step, then track it in Linear. Falconer incrementally refreshes changed Linear issues, so a reader can retrieve the latest ingested issue state alongside the incident record instead of relying only on what was true when the postmortem was written.

Can a postmortem be blameless and still name people?

Yes, and it has to be both. Be blameless about cause: if one command took production down, the finding is the system that allowed it, not the person who ran it. Be named about follow-up: every corrective action needs an owner, a ticket, and a date. Google’s SRE workbook treats missing ownership as a defect in the document, and PagerDuty assigns a document owner before the incident call ends.

How do I state customer impact when I do not have clean numbers?

Say what you can measure and mark the rest as an estimate with its basis. Error rate and request volume over the window are usually available even when revenue impact is not. Write the window as detected-to-mitigated and onset-to-recovered separately, because they differ and conflating them understates impact. An estimate labeled as one is defensible six months later. A precise-looking number with no source is not.

How do I make an old postmortem findable when someone asks why a constraint exists?

The document has to be indexed alongside the code, tickets, and runbooks it refers to, not filed in a folder by date. Falconer keeps finished incident reports searchable and cited, so an engineer asking why a fallback exists gets the incident that produced it rather than a shrug in a Slack thread.