An incident report is the written record of something going wrong in production: what broke, how bad it was, how it was fixed, and what will stop it from happening again. A good report turns a stressful outage into something the team can learn from. This guide covers what to include and gives you a template you can copy.
What Is an Incident Report?#
An incident report documents a single unplanned disruption to a service, from detection through resolution. It is written for two audiences: the people who need to understand the impact now, and the people who will read it later to prevent a repeat. The goal is clarity and learning, not blame.
What to Include in an Incident Report#
Every incident report should answer the same core questions. These are the sections worth documenting:
- Summary: One line on what happened, what it affected, and for how long
- Priority: How serious it was (critical, high, medium, or low)
- Status: Open, resolved, or closed
- Timeline: Timestamped key events, from detection to resolution
- Impact: Who and what was affected, and the business cost
- Detection: How the incident was noticed (alert, customer report, dashboard)
- Root cause: What actually caused it, not just the symptom
- Resolution: What was done to fix it
- Action items: Concrete follow-ups with owners to prevent a repeat
Incident Report Template#
Copy this and fill it in. Markdown keeps it portable across tools:
# Incident Report: [short title]- **Priority:** Critical | High | Medium | Low- **Status:** Open | Resolved | Closed- **Date:** YYYY-MM-DD- **Duration:** [start time] to [end time] ([total])- **Author:** [name]## Summary[One or two sentences: what happened, what it affected, how long.]## Impact- Users affected: [number / percentage]- Services affected: [list]- Business impact: [revenue, SLA breach, support load]## Timeline (all times [timezone])- HH:MM - [Detection: how it was noticed]- HH:MM - [Escalation / investigation begins]- HH:MM - [Mitigation applied]- HH:MM - [Service restored]## Root Cause[What actually caused the incident, at the level deep enough to act on.]## Resolution[What was done to resolve it, and how recovery was confirmed.]## Action Items- [ ] [Follow-up] — owner: [name] — due: [date]- [ ] [Follow-up] — owner: [name] — due: [date]
# Incident Report: [short title]- **Priority:** Critical | High | Medium | Low- **Status:** Open | Resolved | Closed- **Date:** YYYY-MM-DD- **Duration:** [start time] to [end time] ([total])- **Author:** [name]## Summary[One or two sentences: what happened, what it affected, how long.]## Impact- Users affected: [number / percentage]- Services affected: [list]- Business impact: [revenue, SLA breach, support load]## Timeline (all times [timezone])- HH:MM - [Detection: how it was noticed]- HH:MM - [Escalation / investigation begins]- HH:MM - [Mitigation applied]- HH:MM - [Service restored]## Root Cause[What actually caused the incident, at the level deep enough to act on.]## Resolution[What was done to resolve it, and how recovery was confirmed.]## Action Items- [ ] [Follow-up] — owner: [name] — due: [date]- [ ] [Follow-up] — owner: [name] — due: [date]
Priority Levels#
Priority sets the urgency and who gets pulled in. A common scale, and the one ObserveOne uses, is four levels:
| Level | Meaning | Example |
|---|---|---|
| Critical | Major outage, most users hit | Checkout down for everyone |
| High | Significant, partial outage | One region or key feature down |
| Medium | Limited impact | Slow responses, a degraded page |
| Low | Little or no user impact | A cosmetic bug, an internal tool |
How to Write Each Section Well#
- Be specific in the summary. "Payments failed for 40 minutes" beats "there was an issue".
- Use real timestamps. A precise timeline is what makes the report useful later.
- Separate symptom from root cause. "The site was slow" is a symptom; "a missing database index" is a cause.
- Make action items real. Each one needs an owner and a due date, or it will not happen.
Common Mistakes to Avoid#
- Blaming a person. Reports should target the system and process, not individuals, or people stop being honest.
- Vague root causes. "Human error" is rarely the real cause; ask why the system allowed it.
- No follow-through. Action items without owners are a wish list, not a plan.
- Writing it too late. Capture the timeline while it is fresh, ideally during the incident.
Incident Report vs Postmortem#
The terms overlap. An incident report is the record of a single event and its resolution. A postmortem is the deeper retrospective that analyzes why it happened and what to change, usually for higher-severity incidents. For small incidents, a good report is enough; for major ones, the report feeds a postmortem.
Conclusion#
A clear incident report captures what broke, the impact, the root cause, and the follow-ups, all without blame. Use the template above as a starting point and adapt the sections to your team.
Every report starts with noticing the incident in the first place. ObserveOne monitors uptime from multiple regions and opens an incident automatically when a check fails, tracking its timeline, priority, and owner in one place, with public status pages to keep users informed.