This agenda is for a service incident review. If you are closing a project without an incident, use deliverables and project decisions as your evidence instead; a deployment-response timeline would answer a different question.
Prepare a review packet
Before the meeting, collect the incident identifier, affected service, known impact, response timeline, and links to the team's evidence. Ask responders to correct the timeline before discussing causes. Keep the source material in the incident record with its existing access controls.
Use a status on every timeline entry: confirmed, reported but unverified, or unknown. Confirmed means the entry points to supplied evidence, not that an AI drafted a convincing sentence. Specify the time zone and distinguish the first observed symptom from the actual incident start if the latter is unknown.
A fictional deployment review
Fictional example: the times, evidence labels, and people below are invented to demonstrate the structure. They are not real incident records. All listed times use UTC.
| Event | Evidence in the fictional packet | Status |
|---|---|---|
| 14:02: release deployment completed | Sample deployment log D1 | Confirmed within the example |
| 14:06: responder observed failed searches | Sample responder note N1 | Confirmed observation; first failure time unknown |
| 14:10: rollback began | Sample command log D2 | Confirmed within the example |
| 14:18: search check passed after rollback | Sample test record T1 | Confirmed check; full impact duration unknown |
| Why the release passed its earlier checks | No supporting record supplied | Unknown |
The eight minutes between rollback start and the passing check are a timestamp interval in this example. They do not establish how long every customer was affected. That distinction belongs in the impact discussion before anyone writes a duration into the summary.
Use 50 minutes to review evidence and response
The timing here is a suggested allocation, not a universal incident policy.
- Purpose and impact, 5 minutes. State the service behavior that failed, the impact you can support, and the remaining gaps. Focus on learning about the system and response.
- Timeline corrections, 12 minutes. Walk from deployment through detection and recovery. For each disputed entry, identify the missing source and someone who can retrieve it.
- Contributing conditions, 15 minutes. Ask what information, checks, permissions, or operating conditions shaped the response. Separate evidence from hypotheses.
- Actions and validation, 12 minutes. Choose actions tied to the conditions discussed. Give each one an owner, due date, and completion check.
- Read-back and unresolved questions, 6 minutes. Confirm corrections, proposed actions, and the next review of outstanding evidence.
“The responder should have noticed sooner” is not a useful action specification. Ask what signal existed, where it was visible, and what alert behavior needs testing. This follows the blameless approach of examining contributing conditions rather than assigning personal fault. Google's postmortem guidance supports that distinction and reviewed follow-up actions.
Turn a condition into something you can verify
In the fictional packet, the alert configuration is missing. Retrieve and review the configuration is an investigation action; change the alert remains a proposal until the gap is established.
Two sample follow-ups are:
- Alert test: Jordan will run a controlled failed-search scenario in the team's permitted test environment by October 22. Completion evidence: test input, expected alert behavior agreed by the team, and recorded actual behavior. This does not claim that a production alert was fixed.
- Rollback rehearsal: Lee will test the documented rollback steps in that environment by October 23. Completion evidence: steps used, observed checks, and discrepancies added to the incident record. A merged documentation change alone does not demonstrate the rehearsal happened.
Read each timeline event beside its evidence status before moving to the condition and action records. The unknown alert configuration remains an investigation question even when the two follow-up proposals are ready to discuss. A reading copy organizes the supplied packet; it does not retrieve missing logs.
Draft your agenda from the incident packet
Write a service-incident post-mortem meeting agenda in US English.
Incident identifier and service: [enter]
Meeting length and participants: [enter]
Time zone: [enter]
Known impact with supporting source links: [paste]
Timeline entries with source links and uncertainty: [paste]
Responder observations and hypotheses: [paste separately]
Existing incident record and issue tracker: [enter]
Review deadline: [enter]
Create a timed agenda for impact, timeline correction, contributing conditions,
action review, and unresolved questions. Make the times sum to the meeting
length. Focus on system conditions and information available to responders.
Do not invent timestamps, customer impact, root causes, evidence links,
participant agreement, or results. Mark missing facts UNKNOWN. Separate
investigation actions from proposed corrective actions. Each action needs
an owner or OWNER TO CONFIRM, due date or DATE TO CONFIRM, and observable
completion evidence. Preserve source links exactly.
Return a text review packet. Optionally include a sanitized HTML reading copy
with timeline-event evidence details and separate conditions/actions views.
Only use material I have explicitly approved for that copy. Do not add log
integrations, data collection, publishing, or replacement issue tracking.
Finish the meeting by reading the unresolved questions and action checks aloud. Record corrections in the incident document and put accepted follow-ups in the team's issue tracker. The next reviewer should be able to distinguish a completed fix from an explanation that is still awaiting evidence.
Optional: read a sanitized review in NOS
For a separately prepared HTML copy, NOS can save and display the timeline and action summary. Use it to inspect whether an event's evidence label is understandable. Keep original logs, sensitive details, approvals, and action tracking in the team's established records.