A completed example
This fictional example shows the level of detail to aim for. It is not a customer's work history.
Incident postmortem: Saved-card payments failing in checkout Incident ID: INC-0412 Date: Tuesday, 14 October Severity: SEV-2 Status: Resolved, action items open Author: Priya N., for the Payments team Review meeting: Thursday, 16 October, 10:00 Summary For 47 minutes, customers paying with saved cards in the Harbor checkout saw payment errors. A scheduled job rotated the payment gateway key, and the payments service kept using the old key from its cache. Impact - Saved-card payments failed from 14:12 to 14:59. - New-card payments and refunds were not affected. - Support received about 60 tickets. Affected customers were emailed on 15 October. Timeline (local time) - 14:05 Scheduled secrets rotation job replaces the gateway key. - 14:12 Payment failure alert fires in the payments channel. - 14:20 On-call engineer acknowledges and reviews recent deploys. - 14:34 Team finds the gateway returning authentication errors. - 14:51 Payments service restarted to load the new key. - 14:59 Payments recover and the incident is marked mitigated. What went well - The alert fired seven minutes after the first failure. What was hard - Rotation jobs do not appear in the deploy log, so they were not checked first. Contributing factors - The payments service caches the gateway key until restart. - The rotation runbook has no restart or verification step. Action items - Reload the gateway key without a restart. Owner: Payments team. Due: 31 October. Status: In progress. - Show rotation jobs in the deploy log. Owner: Platform team. Due: 24 October. Status: Done. - Add a verification step to the rotation runbook. Owner: Marcus T. Due: 28 October. Status: Not started.
Make it yours
Your draft
The example is fictional. Edits stay in this page and disappear when you leave. Copy or download your work to keep it.
How to fill it in
- Fill in the header and the impact section first, using times from your alerts and dashboards rather than memory.
- Build the timeline from logs, alert history and chat messages, writing one line per event and naming roles, such as on-call engineer, instead of people.
- Write each contributing factor as a condition of the system or process, then ask whether someone else in the same situation would likely have made the same call.
- Give every action item one owner, a due date and a status, and drop any item nobody is willing to own.
- Share the draft with everyone who responded before the review meeting so they can correct times and add context.
Start from your actual work
On a Mac, Dayflow can help you remember the work behind the update. It drafts a timeline from screen activity. Export a date range as Markdown from Settings → Export. Review that record alongside your calendar and task tracker, then fill in the template above.
For a guided walkthrough, see exporting your work history or drafting a report with Claude Code. Check the assistant's draft before sending it.
Local AI keeps screenshot analysis on-device. Your own cloud provider or Dayflow Pro processes selected screenshots off-device. An assistant can receive the Dayflow data it retrieves in your conversation. Local storage does not make a cloud assistant conversation local. Read the data-flow guide before choosing a workflow.
Questions about this template
What does a blameless postmortem mean?
A blameless postmortem assumes the people involved acted reasonably with the information they had at the time. It focuses on the systems, tools and processes that allowed the incident, not on who pressed which button. People still describe their actions honestly, but the goal is to fix conditions so the next person in the same spot is protected.
When should you write an incident postmortem?
Most teams write one after any incident above an agreed severity, after data loss, or whenever customers were noticeably affected. Start the draft within a day or two while details are fresh, and hold the review meeting within the week. Smaller incidents can use a shortened version with just the summary, timeline and action items.
Is a postmortem the same as a customer incident report?
No. A postmortem is an internal working document written for the team that will fix the problem, and it can include rough notes and internal system names. A customer-facing incident report or status update is shorter and edited for an outside audience. Many teams write the postmortem first, then adapt the summary and impact sections for customers.
Who should write the postmortem?
Usually the incident lead or the on-call engineer who handled the response writes the first draft, since they hold most of the context. Everyone who took part should review it and correct the timeline. The author is a facilitator, not a judge, and should not be the only person assigned action items.
How do I rebuild an accurate incident timeline?
Pull timestamps from alert history, deploy logs, chat channels and ticket updates, then line them up in one list. For your own actions, Dayflow can draft a timeline from your screen activity on a Mac, which may help you recall when you switched tasks. Check it against system logs and add calls or offline work it could not see.
What makes a good postmortem action item?
A good action item is a specific change that reduces the chance or impact of a repeat, such as adding a verification step to a runbook. It has one owner, a due date and a status that gets updated. Avoid vague items like 'be more careful', which put the burden on people instead of fixing the system.
Use the right format for the next step
- Weekly status report for a concise progress update.
- Daily work log for a record you can come back to.
- Daily standup template for yesterday, today, and blockers.
Download Dayflow