Incident Report Template
An incident report template gives your team one consistent way to record what went wrong, who was affected, how you responded, and what you will change so it does not happen again. Use this free incident report template for service outages, security events, and data issues, then keep every report in one searchable place so the lessons outlast the people who learned them.
Download for Word
Claude
ChatGPTI need to write an Incident Report. Act as an expert technical writer and draft one for me. Use this structure, keeping each section clear, concise, and genuinely useful to the reader: 1. Incident title and ID 2. Summary 3. Impact 4. Detection 5. Timeline 6. Response 7. Root cause 8. What went well and what did not 9. Follow-up actions 10. Sign-off and history Before you begin, ask me for the details you need: the product, team, or audience this is for, and anything specific I should include. Then write the full Incident Report in clean, well-formatted Markdown.
Write an Incident Report using the structure below. Keep each section clear, concise, and genuinely useful to the reader. Structure: 1. Incident title and ID 2. Summary 3. Impact 4. Detection 5. Timeline 6. Response 7. Root cause 8. What went well and what did not 9. Follow-up actions 10. Sign-off and history Use rich formatting so it reads well in a knowledge base: - Clear headings and subheadings for each section. - Callout boxes for asides: a Tip callout for advice, a Note callout for helpful context, and a Warning callout for anything a reader must not miss. - Tables for structured or comparison content. - Numbered lists for sequential steps and bulleted lists for options. - Bold for key terms and any values people must not get wrong.
Connected HelpDocs over MCP? Add "save this as an unpublished HelpDocs article" to the prompt and the draft lands in your knowledge base, ready to review.
## The incident report template ### 1. Incident title and ID Give it a short, specific title that spells out the symptom, like "Checkout failing for EU customers", and pair it with a unique ID. Also note the severity level and where things stand right now: investigating, mitigated, resolved, or closed. ### 2. Summary Keep it to two or three sentences: what went down, how long it dragged on, and who got caught up in it. You're writing for folks outside the team, so they need the whole story in thirty seconds. ### 3. Impact Be specific about what the impact actually was. - **Who got affected:** the customers, regions, internal teams, or on-site folks who felt it - **What got affected:** the services, features, data, equipment, or locations that took a hit - **How bad it got:** a full outage, slower performance, exposed data, injuries, or damage - **How long it lasted:** when the impact began and when it wrapped up ### 4. Detection Describe how you first learned about the problem, whether that came from an alert firing, a customer reporting in, a teammate catching it, or a routine check. Also record how long the incident went on before anyone realized it was happening. ### 5. Timeline List what happened and what the team did, with timestamps, in chronological order. Pick a single time zone for the whole log and name it. | Time | Event or action | Who | | --- | --- | --- | | TODO | Incident began | TODO | | TODO | Incident detected | TODO | | TODO | Mitigation applied | TODO | | TODO | Incident resolved | TODO | ### 6. Response Share how the team contained and resolved the incident, covering any workarounds, rollbacks, or messages you sent to customers or staff. If you followed a runbook or plan, link to it. ### 7. Root cause Dig below the surface trigger to uncover what really set the incident off. Keep drilling into "why" until you hit something you can really fix. Also flag anything that fed into the problem, like missing alerts or fuzzy ownership. ### 8. What went well and what did not Keep this list short and free of blame. Note what helped the response along and what held things up. Keep your eyes on systems and processes, not on specific people. ### 9. Follow-up actions All the fixes you'll commit to so this doesn't happen again, or so the impact stays smaller if it does. Give every one an owner and a due date. | Action | Owner | Due date | Status | | --- | --- | --- | --- | | TODO | TODO | TODO | Open | ### 10. Sign-off and history Here you'll find the reviewers and approvers, the date the report was closed, and any updates made after that. | Version | Date | Author | Change | | --- | --- | --- | --- | | 1.0 | TODO | TODO | Initial report |
The incident report template
Start a new article with this structure the moment an incident gets declared, then work through it as things unfold. Using the same headings every time means you can compare and search reports against each other.
1. Incident title and ID
Give it a short, specific title that spells out the symptom, like “Checkout failing for EU customers”, and pair it with a unique ID. Also note the severity level and where things stand right now: investigating, mitigated, resolved, or closed.
2. Summary
Keep it to two or three sentences: what went down, how long it dragged on, and who got caught up in it. You’re writing for folks outside the team, so they need the whole story in thirty seconds.
3. Impact
Be specific about what the impact actually was.
- Who got affected: the customers, regions, internal teams, or on-site folks who felt it
- What got affected: the services, features, data, equipment, or locations that took a hit
- How bad it got: a full outage, slower performance, exposed data, injuries, or damage
- How long it lasted: when the impact began and when it wrapped up
4. Detection
Describe how you first learned about the problem, whether that came from an alert firing, a customer reporting in, a teammate catching it, or a routine check. Also record how long the incident went on before anyone realized it was happening.
5. Timeline
List what happened and what the team did, with timestamps, in chronological order. Pick a single time zone for the whole log and name it.
| Time | Event or action | Who |
|---|---|---|
| TODO | Incident began | TODO |
| TODO | Incident detected | TODO |
| TODO | Mitigation applied | TODO |
| TODO | Incident resolved | TODO |
6. Response
Share how the team contained and resolved the incident, covering any workarounds, rollbacks, or messages you sent to customers or staff. If you followed a runbook or plan, link to it.
7. Root cause
Dig below the surface trigger to uncover what really set the incident off. Keep drilling into “why” until you hit something you can really fix. Also flag anything that fed into the problem, like missing alerts or fuzzy ownership.
8. What went well and what did not
Keep this list short and free of blame. Note what helped the response along and what held things up. Keep your eyes on systems and processes, not on specific people.
9. Follow-up actions
All the fixes you’ll commit to so this doesn’t happen again, or so the impact stays smaller if it does. Give every one an owner and a due date.
| Action | Owner | Due date | Status |
|---|---|---|---|
| TODO | TODO | TODO | Open |
10. Sign-off and history
Here you’ll find the reviewers and approvers, the date the report was closed, and any updates made after that.
| Version | Date | Author | Change |
|---|---|---|---|
| 1.0 | TODO | TODO | Initial report |
Tip
Make every incident report easy to find in one spot, with access controls that keep sensitive details internal. Start a free HelpDocs trial and get your incident library running today.
How to fill in this incident report template
The strongest incident reports are candid, detailed, and actually completed. Picking up these habits makes it easier:
- Begin writing while the incident is still live. Trying to piece together exact times and choices a week after the fact is tough. Put one person in charge of tracking the timeline as events unfold.
- Stay blameless. Folks open up more when they don’t fear getting singled out. Describe what the system let happen, rather than who fumbled.
- Nail down the impact. “Some users” gives the reader no real information. List the regions, plans, services, or locations that got hit.
- Tell trigger and cause apart. A rough deploy might have set off the outage, yet the missing test or alert is often the deeper cause.
- Every action needs an owner. Follow-ups that have no name attached and no due date tend to evaporate in incident reports.
- Tie it all together. Link the report to the runbook, recovery plan, or troubleshooting article it relates to, and fold what you learned into those documents.
If your incident reviews keep turning up holes in your recovery process, start with our disaster recovery plan template.
Go further
