What Is the Role of an Incident Commander?

Ask five engineering teams how they handle a major outage and you'll get five different processes — but almost all of them, from Google's SRE org to PagerDuty's own on-call rotation, put one person in charge of the response. That's the incident commander (IC): the person accountable for driving an incident to resolution, so everyone else can focus on their piece of it instead of wondering who's actually steering.

For small and medium teams, having someone clearly playing this role — even informally, even without a fancy title — is often the difference between a 20-minute blip and a 3-hour scramble.

What Is an Incident Commander?

The term comes from the Incident Command System (ICS), a structure originally built to coordinate fire, police, and other emergency responders across agencies. Google adapted it for production outages, and it's since become the default model most tech companies reach for.

You'll also see the role called Incident Manager — that's the term GitLab uses for this rotation in their own public engineering handbook. Different label, same job: one person owns the incident end-to-end. This post uses "incident commander" since it's the term most people search for, but treat the two as interchangeable.

Two things worth correcting up front, because they trip people up:

First, IC is a coordination role, not necessarily a technical one. PagerDuty trains non-engineers to do it, on the basis that the job is to coordinate the response, not make the technical fix. If you can stay level-headed, ask sharp questions, and make a call with incomplete information, you can be trained as an IC — engineering background optional.

Second, for the duration of the incident, the IC's authority isn't set by the normal org chart. A VP joining the call doesn't automatically outrank the IC. We'll get into how real teams actually enforce that further down.

How Someone Becomes Incident Commander

IC usually isn't a permanent title — it's a role people rotate through, tied to an on-call schedule. Whoever's on the IC rotation when something breaks becomes IC for that incident, by default.

Some companies route this by severity instead of a single flat rotation. GitLab, for example, runs two separate on-call rotations: their regular Engineer On Call automatically leads lower-severity incidents, while a broader, dedicated Incident Manager rotation automatically takes over once an incident is classified as high-severity. It's a simple way to keep small issues lightweight while making sure serious ones get an experienced hand immediately.

For a smaller team, this can be as simple as "whoever's on call this week is IC for anything that comes up." You don't need a formal rotation system to get the benefit — you just need it decided, in writing, before an incident starts, rather than sorted out live while something's on fire.

Key Responsibilities

Assess Severity and Set the Response Scale

The first job is figuring out how bad this actually is: what's affected, how many people it's hitting, and whether it's getting worse. This assessment decides everything downstream — how many people get pulled in, how often you communicate, and how the incident eventually gets classified for the postmortem.

Most teams use a simple severity scale (e.g., SEV1–SEV4, or critical/major/minor), and it's worth deciding what triggers each level in advance rather than debating it mid-incident. One extra guideline worth adopting: don't argue about severity during the incident itself. Treat it as the worst case it could plausibly be, and reclassify afterward if it turns out smaller — arguing about labels wastes time you don't have.

Set the Response Strategy

Once severity is clear, the IC defines what "done" looks like — contain the impact, restore service, communicate to affected users — and figures out who and what's needed to get there. This doesn't need to be a formal document for a small incident; for anything involving more than two or three people, though, writing down the plan (even three bullet points) saves a lot of re-explaining.

Communicate With Stakeholders

The IC keeps everyone — responders, leadership, and (via whoever owns customer comms) affected users — updated on what's happening and what's changed. This includes translating technical detail into plain language for non-technical stakeholders, and deciding the cadence of updates so people aren't left guessing or pinging the incident channel every five minutes for a status check.

Coordinate the Response — Don't Perform It

This is the responsibility that gets misunderstood most often. The IC's job is to delegate, not debug. PagerDuty's own guidance is blunt about this: an incident commander "should not be performing any actions or remediations, checking graphs, or investigating logs" — those are jobs for the people actually working the problem. The moment an IC opens a dashboard to check something themselves, they've stopped coordinating, and the response loses its coordinator.

In practice, this mostly comes down to how the IC talks: asking questions ("what do we know?", "what are our options?"), and assigning specific work to a named person with a clear time-box ("[Name], can you check X and report back in 10 minutes?") rather than throwing a task out to the group and hoping someone picks it up.

Keep a Live, Shared Record

Somebody needs to be writing down what's happening as it happens: what's been tried, what the current status is, who's doing what. Google's SRE team calls maintaining this "living incident document" the commander's single most important responsibility — it's what lets someone joining an hour into the incident get up to speed in thirty seconds instead of asking everyone to repeat themselves, and it's what makes the postmortem afterward accurate instead of reconstructed from memory.

For a small team this doesn't need a separate tool — a pinned message in the incident channel, updated every 10–15 minutes, does the job. What matters is that it exists and someone owns updating it, not that it's fancy.

Declare Resolution Against Clear Exit Criteria

Rather than declaring an incident over because it "feels" resolved, decide upfront what resolution actually requires — e.g., error rates back to baseline for 30 minutes, the fix deployed and verified, no related alerts firing. Writing this down at the start of the incident (not the end) keeps you from closing it out too early, and gives the IC a clear, defensible answer when someone asks "are we done yet?"

Resolution isn't the end of the IC's job, either — kicking off the postmortem while details are still fresh (even just creating the doc and assigning an owner) is a lot easier to do in the minutes right after an incident than a week later.

Right-Sizing the Team Around the IC

Larger organizations sometimes formalize a whole cast of roles around the IC — a dedicated notetaker, a person handling only customer communications, and so on. For a small or medium team, you don't need to adopt all of that to get the benefit, and defining roles nobody has time to fill just adds overhead.

The one thing worth protecting regardless of team size: the IC and the person actually touching the system shouldn't be the same person. If your IC is also the one restarting servers and reading logs, you don't really have a coordinator — you have someone debugging alone with extra paperwork. Even a team of three can apply this: one person commands, someone else executes.

Beyond that, additional jobs — drafting a customer update, keeping the timeline current — can just be extra hats a teammate picks up for that specific call, rather than standing job titles you predefine. As incident volume or complexity grows, it starts to make sense to split these off more formally. Until then, let the IC delegate them on the fly.

Handoffs and the Incident Record

Most incidents at a small company resolve within one person's shift, so this won't come up often — but it's worth knowing how to handle it when an incident runs long enough that the current IC needs relief (end of a work day, fatigue, or a personal emergency).

The handoff itself should be explicit and out loud, not assumed. The outgoing IC states clearly, on the call or in the channel, that command is transferring and to whom, and doesn't consider themselves off the hook until the incoming IC has confirmed. If you're keeping a live incident record, update who's currently commanding at the top of it — anyone joining mid-incident should be able to tell at a glance who's in charge without having to ask.

This is also where the connection to your public updates becomes obvious: your live incident record — like the timeline StatusPal Next's incident management keeps automatically as you work the incident — is the internal source of truth, and the status page updates that go out from it are essentially a filtered, customer-safe version of the same timeline. Keeping the internal record disciplined makes the external updates easier to write, not harder.

What Makes a Good Incident Commander

Skip the generic "strong leader, great communicator" checklist — here's what actually matters in practice, based on how companies that run this process daily train for it:

• Communicates clearly under pressure, and isn't afraid of brief silences while gathering information instead of filling them with guesses.
• Can make a decision with incomplete information — a wrong call made quickly and corrected is usually better than no call at all.
• Has sat in on at least a couple of real incidents before running one solo. Shadowing works; there's no substitute for having seen the process in motion.
• Is comfortable asserting the role, including with someone more senior. If an executive jumps on the call and starts issuing contradictory instructions, the IC's job is to ask directly whether they want to take command — not to quietly go along with it while still nominally "in charge." Either the exec takes over explicitly, or the IC's call stands.
• Doesn't need to be the most senior engineer in the room. Coordination and technical depth are different skills, and conflating them is why some teams default to "whoever's the most senior person available" — which usually isn't the best IC, and definitely isn't sustainable as a rotation.

Enhance Your Incident Commander's Toolkit With StatusPal

An IC is only as effective as the tools backing them up. StatusPal Next drops your team straight into a structured incident workspace the moment something breaks — with role assignments, a running timeline, and status page updates all in the same place, so the live record covered above isn't a separate chore layered on top of actually fixing things.

Sign up for a free trial today and give your next incident commander the setup to match the responsibility.

Sources

• Google SRE Book — Chapter 14: Managing Incidents
• Google SRE Book — Appendix C: Example Incident State Document
• PagerDuty Incident Response Documentation — Incident Commander Training
• PagerDuty Incident Response Documentation — Different Roles
• GitLab Handbook — Incident Management