Hold the postmortem meeting within a few days of resolution. One published process schedules it within 3 calendar days for a top severity incident and 5 business days for the next level. Memory fades fast, and delay is a documented reason incidents repeat.
Why speed matters
People forget the order of events, the reasons for a decision and the thing they almost tried. Logs help, but logs do not hold intent. A postmortem written weeks later reads like a reconstruction.
Google's Site Reliability Workbook shows the cost. In its example, a postmortem was published four months after the incident. In the meantime a similar incident occurred, and the team lacked the details a timely write-up would have captured. The Workbook lists delayed publication as a common failure mode.
A workable schedule
PagerDuty's public incident response guide gives a concrete pattern. The postmortem owner books the meeting first, before filling in the document, so the date exists on the shared calendar. For its top severity that is within 3 calendar days, and for the second level within 5 business days. The owner posts the draft for internal review about 24 hours before the meeting so the meeting is not spent on style comments.
Here is a version you can adapt:
| Day | Step |
|---|---|
| Day 0 | Incident resolved. Owner named. Meeting booked. |
| Day 1 | Draft timeline from chat, tickets and logs. |
| Day 2 | Draft shared for comments, at least a day before the meeting. |
| Day 3 | Short review meeting. Facts, causes, actions. |
| Day 4 to 5 | Actions filed as tickets with owners. Summary shared widely. |
For a smaller team, stretch the numbers but keep the order: book first, draft second, review third.
What if people are still tired or the investigation is open
Security incidents can run long, and forensic work may not be done in three days. Separate two things:
- The learning meeting, which covers what the team did and saw. This can happen on schedule.
- The final root cause analysis, which can stay open and be added later with a clear note at the top that the document is a draft.
Mark the status honestly. PagerDuty uses simple statuses (draft, in review, reviewed, closed), which makes it plain how far along a document is. If legal review is involved, plan for it in the schedule. Our post on pre-incident legal readiness covers how to arrange that ahead of time.
Mistakes to avoid
- Waiting for a perfect document. A rough timeline reviewed on day 3 beats a polished one on day 30.
- Skipping the meeting because the write-up is thorough. Disagreements about facts only surface when people read it together. See how to run a post-incident review without blame.
- Letting the owner also be the only reviewer. Ask someone who was not in the incident to read it cold.
How Safeguard fits
If the incident touched a dependency, evidence such as component versions and where they ran is easier to pull when an SBOM already exists. Safeguard offers SBOM and dependency scanning, and a free scan is available at https://gold.safeguard.sh/scan.
Quick check
Is 3 days a rule?
No. It is one published team's target. Choose a target your team can meet, and write it down.
Should the meeting wait for the root cause?
Not necessarily. Hold the learning meeting on time and mark the root cause section as open if it is.
Sources
- PagerDuty incident response documentation, postmortem process
- Google Site Reliability Workbook, Postmortem Culture
Last reviewed: 19 October 2026.
