methodatlas
DevOps

Incident Command

Turns incident work, roles, and countermeasures into a tangible result by declaring an incident, assigning commander and roles, and closing and reviewing the incident.

Core question
Who is in each role, which effect should be checked next, and when is the next stakeholder update due?
MediumWorkshop + asyncAs needed
Purpose

The method helps clarify incident work, roles, and countermeasures concretely. It aligns incident picture, responsibilities, and next countermeasures. The outcome is captured as incident log, action tracker, and stakeholder updates.

How it works

The team follows the steps: declare the incident, assign the incident commander and roles, define communication channels, track actions and updates, and close and review the incident. Each step is captured visibly. At the end, incident log, action tracker, and stakeholder updates are available so decisions, tests, or actions can follow directly.

Visual orientation

Method sketch for a quick mental model.

Incident Command · Roles and Communication FlowSeparate Incident Commander, Operations, Communication, and Scribe so decisions remain clear during an incident
Incident CommandThe visual shows separated incident roles, communication flow, and a shared incident channel.Decouple roles during an incidentA clear command structure keeps diagnosis, communication, and logging separate but synchronized.AssignmentUpdateLogStatusSingle sourceIncident Commanderprioritizes, decides, delegatesOperationsdiagnosis and fixComms Leadstakeholder updatesScribetimeline and decisionsCustomer Statusexternally visible#incident-042one channel, one log, clear roles

Flow

  1. 1Declare incident
  2. 2Assign commander and roles
  3. 3Define communication channels
  4. 4Track actions and updates
  5. 5Close and review incident

The runsheet guides execution with 5 phases, timeboxes, 6 pitfalls, and clear stop criteria.

Open runsheet

Ideal for

  • Major Incidents
  • On-call Operations
  • Cross-team Response

Not good for

  • Small local bugs
  • Uncoordinated ad-hoc debugging

Deep dive

In detail

Incident Command follows a clear working logic: declare the incident, assign commander and roles, define communication channels, track actions and updates, and close and review the incident. This turns the method into a visible thinking process rather than only a conversation. Participants move step by step from raw material, observations, or options toward a shared structure. As a result, an incident log, action tracker, and stakeholder updates support decisions, learning, or further planning.

Facilitation

Prepare a clear guiding question, the right information, and a visible workspace. Plan as needed with 4-15 people and use the format in a workshop or asynchronously. The method needs clear structure and preparation; short timeboxes, visible intermediate results, and a parking lot for open questions help.

Output artifacts
Incident LogAction TrackerStakeholder Updates
Tags
Artifact templates
Incident Command Working TemplateCompact working template for Incident Command with context, input, output artifacts, and next step.
markdown

incident-command-working-template.md

Compact working template for Incident Command with context, input, output artifacts, and next step.

Incident Command Working Template

Goal

A role-based approach for coordinating larger incidents.

Context

When and for what do we use this method?

Input

Which data, observations, decisions, or materials are available?

Execution

Short notes along the runsheet.

Output artifacts

  • Incident Log:
  • Action Tracker:
  • Stakeholder Updates:

Assumptions and open questions

  • ...

Decision / Next step

Owner, date, and success signal.

When to choose differently

Short decision aid for existing alternatives.

ChatOps

Statt Incident Command, wenn du operative Schritte direkt im Chat auslösen und für das Team sichtbar halten willst.

Similar methods

All methods