Skip to main content
Incident response is the active, real-time work of handling an incident while it is happening: assembling the right people, diagnosing the problem, mitigating the impact, and communicating with stakeholders until service is restored. Where incident management describes the whole discipline—including prevention, tooling, and learning—incident response is the part that happens under pressure, between the moment an incident is declared and the moment it is resolved.

​
How is incident response different from incident management?

The two terms are often used interchangeably, but the distinction is useful:
  • Incident response is the doing: the live effort during an incident. It starts when an incident is declared and ends when it is resolved.
  • Incident management is the whole discipline: the processes, roles, tooling, metrics, and learning loops that surround response. It includes what happens before an incident (on-call schedules, runbooks, severity definitions) and after (retrospectives, action items, trend analysis).
A team can have excellent responders and still have weak incident management—heroic, reactive response with no follow-through. The reverse is also possible: beautiful process documents that fall apart the first time something actually breaks. Strong organizations invest in both.

​
What are the phases of incident response?

Once an incident is declared, response typically moves through four phases:
  1. Mobilize. Page the right responders, open a dedicated channel, and assign roles. The first few minutes set the tone—an incident commander taking charge early prevents the “everyone watching, nobody driving” failure mode.
  2. Assess. Establish what is broken, who is affected, and how badly. Assign or confirm a severity. Resist the urge to jump straight to fixes before anyone understands the scope of impact.
  3. Mitigate. Stop the customer impact first, even if the fix is temporary—roll back the deploy, fail over to a replica, disable the feature flag. Root-cause analysis can wait; bleeding cannot.
  4. Resolve and hand off. Restore full service, confirm with monitoring (not just a hopeful “looks fine”), communicate the all-clear, and capture the timeline for the retrospective.

​
What does good incident response look like in practice?

Imagine a deploy at 4:50 p.m. on a Friday starts returning 500s on the login endpoint. Within two minutes, an alert pages the on-call engineer, who declares an incident. A channel is created automatically, the incident commander role is claimed, and a second responder joins to check the deploy history. By minute ten, the team has rolled back and error rates return to baseline. A communications update goes out at minute twelve, and the incident is resolved with a full timeline already recorded. Nothing about this requires genius—only preparation: alerting that works, a clear declaration path, and roles people already understand.

​
What are incident response best practices?

Patterns that consistently separate calm responses from chaotic ones:
  • Declare early and often. A false alarm costs minutes; a late declaration costs hours. Make declaring an incident cheap and blameless.
  • Assign a single incident commander. One person owns the process so everyone else can investigate.
  • Mitigate before you diagnose. Prefer the fastest safe path to reducing impact, then investigate at leisure.
  • Communicate on a cadence. Post updates at predictable intervals—even “no new information” beats silence for stakeholders.
  • Keep the timeline as you go. Reconstructing events after the fact is lossy; capturing decisions in the moment makes the retrospective honest.
  • Separate the fix from the follow-up. Ship the mitigation now; file the durable fix as a tracked action item.

​
Who is involved in incident response?

The core responders are usually the on-call engineer for the affected service plus anyone they escalate to. Around them sit the structured roles—commander, communications lead, scribe—and, for severe incidents, stakeholders such as support leads or executives who consume updates but stay out of the technical channel. The response team should be as small as possible while still covering the needed expertise: every extra person in the room adds coordination cost. Browse all definitions in the incident management glossary.