> ## Documentation Index > Fetch the complete documentation index at: https://docs.rootly.com/llms.txt > Use this file to discover all available pages before exploring further. # What Is an Incident Commander? > An incident commander leads the response to an incident—coordinating people, decisions, and communication. Learn the role, skills, and how to assign one. An **incident commander** is the person who leads the response to an incident. They coordinate responders, drive decisions, and keep the response organized so that everyone else can focus on investigating and fixing the problem. The incident commander does not need to be the most senior engineer in the room—their job is to run the response, not to personally resolve the issue. The role originated in emergency services (the Incident Command System used by firefighters and disaster responders) and was adopted by software teams because it solves the same problem: when something is on fire, someone needs to be clearly in charge. ## What does an incident commander do? During an incident, the commander owns the *process* of the response. While a technical lead digs into logs and a communications lead drafts status updates, the incident commander maintains the big picture: What do we know? What are we trying next? Who is doing what? When do we update stakeholders? Without a commander, incidents tend to drift. Multiple people investigate the same theory, no one updates the status page, and decisions stall because nobody feels authorized to make them. A commander removes that ambiguity—every question about the response has a clear owner. ## Incident commander responsibilities The exact scope varies by organization, but incident commanders typically: * **Declare and scope the incident** — confirm severity, impact, and which services are affected. * **Assemble the response team** — pull in the right responders and assign roles like technical lead, communications lead, and scribe. * **Drive decisions** — choose between mitigation options, approve risky actions like rollbacks or failovers, and break ties when responders disagree. * **Manage communication cadence** — make sure stakeholders, support teams, and customers get timely updates, even if someone else writes them. * **Track the state of the response** — keep a running picture of what has been tried, what is in progress, and what comes next. * **Manage responder workload** — rotate people out of long incidents and escalate when the team needs more help. * **Hand off cleanly** — brief the next commander during long-running incidents, and kick off the retrospective once the incident is resolved. ## What makes a good incident commander? Good incident commanders are calm under pressure, decisive with incomplete information, and comfortable delegating. Deep technical knowledge of the affected system helps but is not required—in fact, commanders who dive into debugging themselves usually stop commanding, which is the failure mode the role exists to prevent. Look for people who: * Communicate clearly and summarize well, especially in writing * Ask direct questions ("What do we know? What's blocking you?") rather than speculating * Make timeboxed decisions instead of waiting for perfect information * Stay blameless and keep the response focused on mitigation, not fault Many teams train a rotating pool of incident commanders rather than relying on one or two heroes. This spreads the load, avoids single points of failure, and builds incident skills across the organization. ## Incident commander vs. incident manager vs. on-call engineer These titles are often used loosely, but they describe different things: * **Incident commander** — leads a *specific incident* from declaration to resolution. It's a temporary, per-incident role, not a job title. * **Incident manager** — often a permanent job function focused on the incident *program*: process design, tooling, metrics, and post-incident follow-through. In some organizations "incident manager" is simply their name for the commander role. * **On-call engineer** — the person paged first when something breaks. They triage and often resolve small incidents alone. For larger incidents, they may become the incident commander, or they may declare the incident and hand command to someone else while they investigate as technical lead. The key distinction: on-call determines *who responds first*, while incident command determines *who runs the response*. They can be the same person, but for high-severity incidents it is usually better to separate them. ## How to assign incident commanders automatically Manually figuring out who should command an incident at 3 a.m. wastes the minutes that matter most. In Rootly, incident commander is a configurable [incident role](/incidents/incident-roles/incident-roles)—alongside roles like technical lead, communications lead, and scribe—with clear ownership visible in the incident sidebar, Slack summaries, and the incident timeline. You can fill the role automatically using [workflows](/workflows/workflows), Rootly's automation engine. A workflow can assign the incident commander based on severity, impacted services, incident type, or the current on-call schedule—so the moment a SEV1 is declared, command is already assigned and announced in the incident channel. Responders can also assign or reassign the role directly from Slack, and every change is tracked in the timeline for the retrospective. You can also just ask. Mention `@Rootly` in the incident channel and tell the [Rootly AI agent](/ai/rootly-in-slack/overview) to assign roles—"make me the incident commander" or "assign Priya as communications lead"—and it applies the change and announces it, without opening a form. To get started, see [Managing Incident Roles Through the Web Interface](/incidents/incident-roles/managing-incident-roles-through-the-web) or [Managing Incident Roles Through Slack](/incidents/incident-roles/managing-incident-roles-through-slack).