methodatlas
Method guideDevOps

Incident Command

A practical method guide: clarify prerequisites and materials, understand the complete process, and look up outputs, pitfalls, and stop criteria.

ComplexityMedium
TimeAs needed
Participants4-15
FormatWorkshop + async
MaturityEstablished
Prepare plan
01

Prerequisite

What needs to be finished first

Complete firstClear scope

An active incident requiring coordination, multiple responders, or external communication.

Without a boundary, data, perspectives, or flows become mixed.
Complete firstAccess to evidence

Relevant people and sources can be included.

Gaps remain visible; missing evidence must not be invented.
02

Preparation

What needs to be ready before start

Materials

Shared workspace, accessible sources, and a decision log.

People / roles

Incident Commander · Operations · Communications · scribe

Pre-read

Clarify the question, timeframe, data access, roles, and known uncertainties in advance.

Time needed

For the duration of the incident; roles, update cadence, and handoffs adapt to the situation.

Setup

Create a shared version. Label facts, assumptions, and decisions separately.

03

Core question

The one question this method answers

Who commands, who works the technical problem, and how do we maintain a shared situation?

04

Flow

Phases with goal, actions, output and pitfall

Incident Command coordinates an active major incident through clear command, a shared situation picture, communication, and a documented handoff. The method connects operational control with traceable transfer of responsibility.

Situation, workstreams, and handoff

Fictional worked example

Coordinate an active major incident with clear command, shared situation, communication, and documented handoff.

Situation

Record severity, Incident Commander, and start time.

Payment confirmations delayed; SEV-1 declared at 14:05.

Roles

Separate confirmed facts, hypotheses, impact, and open questions.

IC: Sam; Operations: Jo; Communications: Lee; Scribe: Pat.

Cadence

Assign workstreams, update cadence, and audience.

15-minute situation update; one incident log; technical changes have an owner.

Handoff

Document stability criteria, residual risk, and accepted handoff.

After queue stabilizes: IC hands off to service owner; schedule separate learning review.

Fictional: payment confirmation outage. Incident Commander coordinates and sets 15-minute updates; Operations Lead checks backlog and rollback; Communications Lead publishes customer status; Scribe logs timestamps. Once stable, roles are formally handed off and a separate postmortem is scheduled.

Incident management at Google · Google Cloud

  1. 1

    Command

    Declare and lead

    Goal

    Is one person clearly accountable for coordination?

    Inputs for this step

    • Incident symptoms, severity, and responders

    Actions

    • Set severity and objectives; name Incident Commander and assign roles.
    • Is one person clearly accountable for coordination?

    Output

    Incident declaration and commander

    Incident declaration and commander

    Quality check

    Is one person clearly accountable for coordination?

    Pitfall

    Commander also executes technical tasks Separate command from hands-on investigation as the response grows.

    Timing: Part of the agreed work block; research may be separate.

  2. 2

    Situation

    Establish situation

    Goal

    Are unresolved assumptions marked?

    Inputs for this step

    • Confirmed facts, impact, and systems

    Actions

    • Collect symptoms, user impact, systems, and confirmed facts in one log.
    • Are unresolved assumptions marked?

    Output

    Shared situation and impact summary

    Shared situation and impact summary

    Quality check

    Are unresolved assumptions marked?

    Pitfall

    Multiple situation reports conflict Use one incident log and one authoritative status source.

    Timing: Part of the agreed work block; research may be separate.

  3. 3

    Coordination

    Coordinate work and communication

    Goal

    Can responders help without conflicting parallel commands?

    Inputs for this step

    • Roles, workstreams, and update audience

    Actions

    • Assign technical workstreams; set status cadence and audience.
    • Can responders help without conflicting parallel commands?

    Output

    Coordinated technical and communications work

    Coordinated technical and communications work

    Quality check

    Can responders help without conflicting parallel commands?

    Pitfall

    Unverified theory shared as fact Distinguish confirmed, suspected, and unknown in updates.

    Timing: Part of the agreed work block; research may be separate.

  4. 4

    Handover

    Stabilize and hand off

    Goal

    Are service and command responsibilities clearly handed off?

    Inputs for this step

    • Stability evidence, open risks, and handoff

    Actions

    • Verify recovery, state residual risks, document command handoff, and schedule review.
    • Are service and command responsibilities clearly handed off?

    Output

    Documented stabilization and command handoff

    Documented stabilization and command handoff

    Quality check

    Are service and command responsibilities clearly handed off?

    Pitfall

    Handoff without explicit acceptance Incoming command explicitly accepts situation, goals, and open risks.

    Timing: Part of the agreed work block; research may be separate.

05

Artifact

What comes out at the end

Sketch: what the artifact looks like

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
Form

Versioned result with question, evidence, open issues, next action, ownership, and review date.

Versioning / ownership

Record date, scope, sources, and changes. Preserve earlier observations.

Tool alternatives
  • Whiteboard or paper
  • Shared spreadsheet
  • Versioned project space

incident-command-working-template.md

Prepare Incident Command with a clear question, roles, and sources.

Incident Command: Worksheet

Question

To be confirmed

Desired outcome

To be confirmed

Scope

Plan the full method Time: Set according to scope and available evidence

Complete this worksheet on paper or in your own document during the work.

Preparation for this scope

Method setup

  • Materials: Shared workspace, accessible sources, and a decision log.
  • Roles: Incident Commander · Operations · Communications · scribe
  • Advance information: Clarify the question, timeframe, data access, roles, and known uncertainties in advance.
  • Overall time needed: For the duration of the incident; roles, update cadence, and handoffs adapt to the situation.
  • Setup: Create a shared version. Label facts, assumptions, and decisions separately.

Prepare for the work steps

Command: Declare and lead

  • Incident symptoms, severity, and responders

Situation: Establish situation

  • Confirmed facts, impact, and systems

Coordination: Coordinate work and communication

  • Roles, workstreams, and update audience

Handover: Stabilize and hand off

  • Stability evidence, open risks, and handoff

Situation, workstreams, and handoff

Situation

Record severity, Incident Commander, and start time.

...

Roles

Separate confirmed facts, hypotheses, impact, and open questions.

...

Cadence

Assign workstreams, update cadence, and audience.

...

Handoff

Document stability criteria, residual risk, and accepted handoff.

...

Blank worksheet: start with a bounded question. Enter observed facts only, mark assumptions, and record open questions and sources.

Incident management at Google · Google Cloud

Command: Declare and lead

Expected artifact: Incident declaration and commander

Incident declaration and commander

Entry:

...

  • Is one person clearly accountable for coordination?

Situation: Establish situation

Expected artifact: Shared situation and impact summary

Shared situation and impact summary

Entry:

...

  • Are unresolved assumptions marked?

Coordination: Coordinate work and communication

Expected artifact: Coordinated technical and communications work

Coordinated technical and communications work

Entry:

...

  • Can responders help without conflicting parallel commands?

Handover: Stabilize and hand off

Expected artifact: Documented stabilization and command handoff

Documented stabilization and command handoff

Entry:

...

  • Are service and command responsibilities clearly handed off?

Open questions and next steps

...

Method guide: https://methodatlas.meierhoff-systems.de/en/methods/incident-command/run-sheet

06

Example output

Concrete filled scenario, fictional example

Fictional example for orientation. Counts and timings describe this case and are not universal requirements.

incident-command-beispiel.md

Concrete filled scenario, fictional example

Fictional worked example

Fictional: payment confirmation outage. Incident Commander coordinates and sets 15-minute updates; Operations Lead checks backlog and rollback; Communications Lead publishes customer status; Scribe logs timestamps. Once stable, roles are formally handed off and a separate postmortem is scheduled.

All names and values are invented for illustration. Unresolved explanations remain questions.

07

Pitfalls

Recognize symptoms and steer against them

Quick overview, the full text is in the matching phase in the flow

  1. Declare and leadCommander also executes technical tasksView in phase
  2. Establish situationMultiple situation reports conflictView in phase
  3. Coordinate work and communicationUnverified theory shared as factView in phase
  4. Stabilize and hand offHandoff without explicit acceptanceView in phase
08

Stop criteria

When to pause, resolve prerequisites, or choose another approach

The question or boundary remains ambiguous: narrow it first.
Key data or participants are missing: label the gap and arrange access.
The group mixes observation and explanation: revisit the evidence.
An immediate safety or operational risk appears: stop and use the responsible procedures.

Method after Incident Command System. Incident Command is based on the Incident Command System and was adapted in IT/SRE contexts. Curated with 1 sources.

Sources: Incident management at Google · Google Cloud

Flow, timeboxes, and pitfalls are editorially curated practice recommendations based on the listed sources.

Where to go next?

Blameless Postmortem workspace showing the question, observations, and next decision.
DevOps
Blameless Postmortem

Examines, after stabilization, how the incident could occur.

Game Day workspace showing the question, observations, and next decision.
DevOps
Game Day

Rehearses the coordination used in the response as a controlled scenario.

View in playbookImprove the Deployment and Platform FlowMove from a simulated outage through practiced incident response to a documented, improved learning loop.

Finished the method guide?

Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.

Go to profileMore methods