How to Run an Incident Response Call in English

Leading an incident response call under pressure is hard enough in your native language — doing it in English adds another layer of difficulty. Clear, calm, structured communication during an incident keeps the team focused and prevents confusion from making the outage worse. This guide gives you the vocabulary and phrases to run an incident call confidently in English, from opening the bridge to handing off to the next shift.

Key Vocabulary

Incident commander (IC) — the person responsible for coordinating the response, making decisions, and keeping communication clear during an incident. “I’ll be incident commander for this one — if you’re actively debugging, please route status updates through me.”

Severity level (SEV) — a classification of how serious an incident is, used to determine urgency and who needs to be involved. “We’re calling this a SEV-1 — full checkout outage — so I’m paging in the payments team lead now.”

Mitigation — an action taken to reduce the impact of an incident, which may not fully resolve the underlying cause. “Rolling back the last deploy is our mitigation — it should stop the errors, even though we haven’t found the root cause yet.”

Root cause — the underlying reason the incident occurred, as opposed to its symptoms or immediate trigger. “The root cause isn’t confirmed yet, but the immediate trigger looks like a config change that shipped an hour ago.”

Blast radius — the scope of systems, users, or data affected by an incident. “The blast radius is limited to EU customers — US traffic is routed through a different cluster and is unaffected.”

Status update (incident) — a periodic, structured summary of what’s known, what’s being done, and what’s next, shared with stakeholders during an incident. “I’ll post a status update every fifteen minutes in the incident channel, even if there’s no new information.”

Handoff — transferring ownership of an ongoing incident to another person or team, typically at a shift change. “I’m handing this off to the next on-call engineer — let me summarise where we are before I go.”

All-clear — the announcement that an incident has been fully resolved and normal operations have resumed. “We’re declaring the all-clear — error rates have been back to baseline for twenty minutes.”

Opening the Call

• “Thanks everyone for joining quickly. I’ll be incident commander. Can I get a quick round of who’s here and what you’re looking at?”
• “Here’s what we know so far: checkout error rates spiked at 14:02 UTC. We don’t yet know the cause.”
• “I’m going to keep this call focused on active debugging — side discussions, let’s take to a separate thread so we don’t lose the signal.”

Giving a Status Update

• “Status update: we’ve confirmed the spike started right after the 14:00 deploy. We’re rolling that back now, ETA five minutes.”
• “No change since the last update — still investigating the database connection pool exhaustion.”
• “Good news: error rates are dropping since the rollback. We’re watching for the next ten minutes before calling it resolved.”

Assigning Roles and Tasks

• “Can someone own communicating with the support team so they can update affected customers? I don’t want that falling through the cracks.”
• “I’ll take point on the rollback. Can you dig into the logs and see if you can isolate which query started timing out?”
• “Let’s not have more than two people directly debugging at once — everyone else, please hold questions until the next update.”

Handing Off or Closing the Incident

• “Before I hand off, here’s where we are: mitigation is in place, root cause is still under investigation, and there’s a follow-up ticket already filed.”
• “I’m declaring the all-clear. I’ll schedule the postmortem for tomorrow morning and share the doc beforehand.”
• “Thanks everyone — great response time. Let’s capture what we learned while it’s fresh, in the postmortem doc.”

Professional Tips

1. Announce your role explicitly at the start of the call. “I’ll be incident commander” prevents confusion about who’s making decisions.
2. Separate mitigation from root cause in your updates. Stakeholders need to know the immediate problem is being addressed, even if the full explanation will take longer.
3. Keep status updates on a predictable cadence. “Every fifteen minutes, even with no news” reduces anxious pings from people waiting for information.

Practice Exercise

1. Write an opening statement (3-4 sentences) for an incident call where you are the incident commander.
2. Write a status update reporting that mitigation is in place but the root cause is still unknown.
3. Write a handoff message summarising an ongoing incident for the next on-call engineer.