# Incident Report
A formal document that details an unplanned event, such as a system outage, security breach, or operational failure. It outlines what happened, the impact, the actions taken to resolve it, and the steps to prevent recurrence. It's a key tool for learning and improvement in IT and software engineering.
**Pronunciation:** /ˈɪnsɪdənt rɪˈpɔːrt/
**Difficulty:** Beginner
**Synonyms:** Postmortem, After-Action Report (AAR), Root Cause Analysis (RCA) Report, Incident Review, Blameless Postmortem
**Categories:** IT Operations, Site Reliability Engineering, DevOps, Cybersecurity
**Tags:** Incident Management, Postmortem, Root Cause Analysis, ITIL, SRE, Security
Canonical: https://scaleengineer.com/glossaries/incident-report
---
## Definitions

- **Incident Report in IT Operations and SRE:** An **Incident Report**, often called a **postmortem** or **after-action report** in modern contexts, is a detailed document created after an unplanned event that disrupts service. Its primary purpose is not to assign blame but to provide a factual account of the incident and facilitate learning to prevent future occurrences.

**Key Components:**
*   **Summary:** A high-level overview of the incident, including what happened, the impact, and the duration.
*   **Timeline:** A chronological log of events, from detection to resolution, including key actions taken by the response team.
*   **Impact:** A detailed description of the consequences, such as user-facing errors, data loss, performance degradation, or financial loss. It often references metrics like Service Level Objectives (SLOs).
*   **Root Cause Analysis (RCA):** An investigation into the underlying causes that led to the incident. This section avoids blaming individuals and focuses on systemic, process, or technical failures.
*   **Resolution:** The steps taken to mitigate the impact and restore the service.
*   **Action Items:** A list of concrete, actionable tasks with assigned owners and deadlines to address the root causes and prevent recurrence.

**Usage:**
Teams use **Incident Reports** to share knowledge across the organization, improve system resilience, and refine their incident response processes. A "blameless" approach is crucial, encouraging honest and open discussion without fear of punishment.

## Etymology

The term combines "incident," from the Latin 'incidere' meaning 'to fall upon, happen to,' and "report," from the Latin 'reportare' meaning 'to carry back.' It literally means 'to carry back [information about] what has happened.'

## First used

1980s

## Historical context

The practice of documenting unexpected events has roots in military and industrial safety, where analyzing failures is crucial to prevent future disasters. Aviation, in particular, has a long history of detailed incident reporting to improve safety protocols.

In the context of IT, the formalization of the **Incident Report** gained traction with the development of the IT Infrastructure Library (ITIL) in the late 1980s. ITIL established a framework for IT Service Management (ITSM), where incident management and reporting are core processes.

The rise of Site Reliability Engineering (SRE), pioneered by Google in the early 2000s, further evolved the concept. SRE culture emphasizes "blameless postmortems," a type of **Incident Report** focused on systemic issues rather than individual errors. This shift encouraged transparency and a culture of learning from failures.

Today, **Incident Reports**, often called **postmortems** or **after-action reports**, are a standard practice in DevOps, SRE, and cybersecurity to ensure system reliability, security, and continuous improvement.

## Q&A

- **What is the primary goal of a modern Incident Report, especially in an SRE or DevOps culture?:** The primary goal is not to assign blame but to learn from the failure. It serves as a tool for continuous improvement by providing a detailed, factual account of what happened, analyzing the root causes, and defining concrete action items to improve system resilience and prevent the incident from happening again. This is often referred to as a 'blameless postmortem'.
- **List three essential components of a comprehensive Incident Report.:** Three essential components are: 
1. A detailed timeline of events from detection to resolution. 
2. A Root Cause Analysis (RCA) that identifies the underlying systemic issues. 
3. A list of actionable follow-up items with owners and due dates to prevent recurrence.
- **Why is a 'blameless' approach important when writing an Incident Report?:** A 'blameless' approach is crucial because it fosters a culture of psychological safety and transparency. When team members are not afraid of being punished for mistakes, they are more likely to be open and honest about the events that occurred. This leads to a more accurate understanding of the root causes and ultimately, more effective preventative measures.

## Usage examples

- After the database outage, the SRE team was tasked with writing a detailed **Incident Report** to identify the root cause.
- The CISO reviewed the security **Incident Report** to understand the attack vector and implement new preventative measures.
- Our company culture promotes a blameless **postmortem**, ensuring the focus of the **Incident Report** is on system improvement, not individual error.
- The **After-Action Report** concluded that a lack of monitoring was a key contributing factor to the prolonged downtime.

## Related terms

- Incident Management
- Root Cause Analysis (RCA)
- Site Reliability Engineering (SRE)
- ITIL
- Service Level Objective (SLO)
- Mean Time To Recovery (MTTR)

## Popular related terms

- Postmortem
- Root Cause Analysis (RCA)
- SRE
- ITIL
- SLO