Turn incident notes into an explanation the next on-call engineer can use. Keep observations, uncertainty, recovery evidence, and follow-up work connected in one review packet.
Incident Postmortem Template for Engineering Teams · Built on the Engineering team
1 / CI Investigation Agent
Separate when an event occurred from when it was observed. Record conflicting clocks and missing intervals rather than filling them from memory.
2 / Engineering Agent
Connect the supported sequence to contributing conditions. Mark hypotheses and name the next evidence needed to confirm them.
3 / QA Agent
Turn lessons into bounded actions with an owner, due date, and completion check. Preserve unresolved recovery or data-impact questions.
Illustrative outputs. Your team works from your own materials.
Fictional example. Replace the records, targets, and decisions with your own evidence.
Incident: DEMO-INC-19, fictional export service; all times UTC.
09:12: queue age alert fired; evidence MON-DEMO-1.
09:18: incident owner paused new exports; evidence CHAT-DEMO-2.
09:31: queue age returned to the agreed range; evidence MON-DEMO-3.
Still open: reconcile which queued exports completed. A healthy chart does not answer that question.
Service restoration and reconciliation of affected work are separate facts. Record both before describing the incident as closed.
This example explains the task. It is not a live run or a customer result.
Start with what you already have. The team can ask for missing details before preparing the next step.
Copy the starting task and adapt it to your work. With the Engineering team in your workspace, share it with Engineering Agent alongside your source materials.
Team installation is currently in limited access. You can explore the team and copy the task and reference files here.
Editable template
incident-postmortem-task.md
# Prepare an incident postmortem draft Engineering Agent: coordinate CI Investigation and QA using the supplied incident record. Incident ID / service / environment: Time zone and observed impact window: Current response owner and recovery status: Authorized source references: Reviewers and permitted audience: Return an evidence-linked timeline, impact statement, contributing conditions, response analysis, and action register. Separate observations from hypotheses. Keep unknown counts unknown. If restoration or affected-work reconciliation is incomplete, name the responsible owner and unresolved question; do not mark the incident closed. Each action needs an owner, due date, verification condition, and completion reference. Do not copy credentials or customer payloads into the report. Do not alter systems, publish the draft, or contact customers. Request missing access explicitly.
Use these editable templates as inputs or work with them on their own. Free to copy and download. Worked examples use fictional records.
Editable template
incident-postmortem-template.md
# Incident postmortem Incident ID: Service / environment: Document version / author / reviewers: Current incident status and evidence: Permitted audience: ## Reader summary Observed symptom, affected task, verified impact, and remaining uncertainty: ## Impact Time window and time zone: Affected population and measurement source: Incomplete work or data reconciliation still needed: ## Evidence timeline | Event time + zone | Observation time | Event | Source | Confidence or unresolved conflict | | --- | --- | --- | --- | --- | | | | | | | ## Contributing conditions Supported causal sequence: Hypotheses and evidence needed: What helped responders / what made the work harder: ## Recovery verification Mitigation taken and authorized owner: Service behavior observed after mitigation: Affected-work outcomes and reconciliation source: Open recovery owner and next checkpoint, if any: ## Follow-up register | Action | Owner | Due date | Acceptance evidence | Status | Completion reference | | --- | --- | --- | --- | --- | --- | | | | | | | | ## Review decision Reviewer / reviewed version / date: Corrections and unresolved questions:
Fictional worked example
incident-postmortem-actions-example.csv
| example | action_id | action | owner | due_date | verification | status | completion_reference |
|---|---|---|---|---|---|---|---|
| fictional | A-01 | Add oldest pending export age alert | Service team | Set at review | Delayed synthetic export produces an alert receipt | proposed | — |
| fictional | A-02 | Reconcile affected export outcomes | Incident owner | Set at review | Every affected export has a verified outcome or assigned recovery | open | — |
Include the scope, observed impact, sourced timeline, contributing conditions, response and recovery evidence, unanswered questions, and follow-up actions. Record the reviewer and document version.
Response restores service and addresses affected work. A postmortem examines the event and assigns improvements. Writing this document must not delay active recovery or imply that an unresolved incident is closed.
Describe the information, system behavior, and constraints that shaped decisions. Examine why a decision made sense at the time rather than naming a person as the root cause.
No. The files are editable starting material. An Offloop team needs separately authorized sources and tools. Review the resulting draft before any external publication or operational action.