# What is Incident?

Also called outage, postmortem, incident response.

An incident is an unplanned disruption or degradation of a service that requires a coordinated response. Handling one typically follows a sequence of detection, triage, mitigation, resolution, and review. The review, often called a postmortem, documents the timeline and contributing causes so that improvements target the conditions that allowed the failure rather than the individuals involved.

Incident response separates mitigation from resolution, and the order matters. Mitigation restores service by any acceptable means, such as rolling back, shedding load, failing over, or disabling a feature. Resolution fixes the underlying defect. Attempting to understand a problem fully before stopping the harm extends customer impact, which is why experienced responders mitigate first and investigate afterward.

Roles reduce chaos during larger incidents. A common structure names one person to coordinate and make decisions, others to investigate, and one to communicate with stakeholders so investigators are not answering status questions. Even in a small team, explicitly saying who is coordinating prevents the situation where several people debug in parallel, unaware they are duplicating or undoing each other's work.

Severity levels classify impact and drive the response, from a full page at any hour down to a routine ticket. Because responders classify under pressure with incomplete information, the sensible bias is to declare high and downgrade later. Downgrading costs little, while an incident that was under classified for an hour has already spent that hour without the attention it needed.

The review is where lasting value comes from. A blameless review reconstructs the timeline, asks why each safeguard did not catch the problem earlier, and produces owned action items. Blamelessness is not politeness; it is what keeps people describing what actually happened. Reviews that assign fault reliably produce sanitized accounts, which removes exactly the information future prevention depends on.

## Key points

- Mitigate to stop impact before diagnosing the root cause.
- Name a coordinator, even for small incidents.
- Declare a high severity early; downgrading is cheap.
- Blameless review keeps the account accurate and useful.
- Reviews produce owned actions, not just a narrative.

## In practice

Agent task failures rise sharply after a deploy. On call declares a high severity, names a coordinator, and rolls back within twelve minutes, restoring normal behavior before the cause is known. Investigation the next day traces it to a schema change incompatible with in flight workflow runs. The review notes that no test covered runs started before a deploy, and an action item adds one, along with an alert on task failure rate.

## Related terms

- [Alerting](/en/glossary/alerting)
- [Rollback](/en/glossary/rollback)
- [Monitoring](/en/glossary/monitoring)
- [Service Level Objective](/en/glossary/service-level-objective)
- [Uptime](/en/glossary/uptime)

[Back to the AI Glossary](/en/glossary)