Incident Response Template for Agile Teams

Within 48 hours of the incident. The details are freshest immediately after resolution, and delaying the postmortem reduces the urgency of action items. Schedule a 1-hour postmortem review meeting within 3 business days of the incident. The author drafts the postmortem, the team reviews it together, and action items are assigned during the meeting.

Everyone who was involved in the incident response, plus the engineering manager and PM for the affected area. For SEV-1 incidents, include a VP or director to ensure action items get prioritized. Keep the group under 10 people. Observers can read the document asynchronously.

For SEV-1 incidents affecting external customers, yes. Publish a simplified version that covers what happened, what the impact was, and what you are doing to prevent recurrence. Omit internal details (team names, specific infrastructure). Companies like [Atlassian](https://www.atlassian.com/trust/incident-management) and [Cloudflare](https://blog.cloudflare.com/tag/post-mortem/) publish detailed public postmortems, and customers consistently report that transparency increases trust.

Track incident action items in the same system you track engineering work (Jira, Linear, Asana). Create a dedicated label or tag (e.g., "incident-action-item"). Review open action items in the weekly engineering standup. Set a team goal: 90%+ of action items closed within 30 days.

A [bug report](/templates/bug-report-template) documents a defect that needs to be fixed. An incident response template manages the real-time response to a production issue and the subsequent investigation. A bug report might result from an incident (e.g., "Fix the reporting query that caused INC-2026-014"), but the incident template covers the full lifecycle: detection, response, communication, resolution, and prevention. ---