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.

Navigating Nuances: Professional Phrasing for Incident Response

Leading an incident response call can be incredibly stressful, but a significant portion of that stress often stems from feeling unsure about how to articulate information clearly and confidently in English. For developers who are still building their professional vocabulary, the specific phrasing used during these calls – particularly when dealing with technical details – can feel overwhelming. It’s not just about conveying the problem; it’s about doing so in a way that fosters collaboration and demonstrates competence. Let’s look at some common scenarios and how to approach them with greater precision.

One key area is describing the impact of an issue. Instead of simply saying “This is broken,” which can sound accusatory or dismissive, consider phrasing like: “We’re observing a degradation in service performance affecting users accessing [specific feature]. Initial data suggests approximately a 15% increase in latency.” This uses precise language – “degradation,” “service performance,” “latency” – and provides quantifiable information. Similarly, when assigning tasks, avoid vague statements such as “Fix this.” Instead, try: “Could you investigate the root cause of the error logs identified in the application server’s event stream? Prioritize identifying any correlation with recent code deployments.” Notice the use of active verbs (“investigate,” “identify”) and a clear objective. It’s also helpful to acknowledge uncertainty; saying “We need to determine the underlying cause” is more professional than stating a definitive conclusion prematurely.

Slack communication during an incident can be equally crucial. Receiving a message like “Something’s not right!” is unhelpful. A better response would be: “I’m seeing elevated error rates on the API endpoint – please review the monitoring dashboards for details.” Or, when submitting a pull request to address a bug, instead of just writing “Fixed bug,” draft a description including: “This PR addresses the intermittent failure reported in [specific area] due to [brief explanation]. I’ve implemented [solution] and included unit tests to ensure functionality. Please review the associated code changes for any potential regressions.” Using terms like “intermittent failure,” “monitoring dashboards,” “regression” demonstrates a deeper understanding of the issue and promotes constructive feedback. Remember, clarity is paramount—even if you don’t fully understand something, asking clarifying questions (“Could you elaborate on what you mean by ‘increased load’?”) is perfectly acceptable and expected.