How to Communicate During a Production Incident

Production incidents are high-stress situations that demand clear, fast communication in English. Whether you are the incident commander, an on-call engineer, or a stakeholder receiving updates, knowing the right phrases and conventions can significantly reduce confusion and speed up resolution.

This guide covers the English patterns used in real-time incident communication — from the first alert to the all-clear.

Opening the Incident

Declaring an Incident

When something goes wrong, the first step is to formally open an incident channel and declare its severity. This signals to the team that structured coordination has begun.

“I’m opening an incident channel for the checkout service degradation. SEV-2. Please join #incident-2026-06-14-checkout.” “Declaring an incident for elevated error rates on the payments API. Assigning myself as incident commander. On-call engineers, please join the bridge.” “We have a P1 — the authentication service is returning 503s. War room is open.”

Key vocabulary:

• SEV-1 / P1 — most critical severity; typically means full outage or significant data loss risk
• SEV-2 / P2 — major degradation affecting a significant portion of users
• War room — a synchronous meeting (video call or physical room) for incident coordination
• Bridge — a conference call for incident coordination

Status Updates

The Anatomy of a Status Update

During an incident, regular updates keep stakeholders informed and reduce the flood of “what’s happening?” messages. A good status update has three parts: what you know, what you’re doing, and when the next update will come.

“Update at 14:45 UTC: We’ve identified the root cause as a database connection pool exhaustion triggered by a spike in traffic. We are currently increasing the pool size and monitoring recovery. Next update in fifteen minutes or sooner if status changes.”

Phrases for Status Updates

Acknowledging the issue:

“We’re aware of the issue and are actively investigating.” “We’ve confirmed the impact: approximately 30% of users in the EU region are affected.”

Describing investigation progress:

“We’re currently working to identify the root cause.” “We’ve narrowed the issue down to the payment processor integration.” “We’re still investigating — early signs point to a configuration change deployed at 14:20 UTC.”

Describing mitigation in progress:

“We’re in the process of rolling back the release.” “A fix is being deployed now. We expect recovery within the next ten to fifteen minutes.” “We’ve applied a temporary mitigation — service is partially restored. We’re continuing to monitor.”

Escalation Language

When to Escalate

Escalation means bringing in additional expertise or authority. You should escalate when the incident exceeds your technical scope, when time-to-resolution is unacceptably long, or when business impact requires executive awareness.

“I’m escalating this to the database team — the root cause appears to be in a component outside my area.” “I’m paging the on-call DBA. We have a suspected index corruption that needs specialist attention.” “I need to loop in the CTO — this incident has been ongoing for ninety minutes and is affecting our SLA with Enterprise customers.”

Escalation Phrases

• “I’m escalating to [team/person] because…”
• “This is beyond my expertise — I need to pull in [specialist].”
• “Given the duration, I’m bumping this to SEV-1.”
• “I’m paging the secondary on-call for additional support.”
• “We need executive awareness on this. I’m sending an update to [stakeholder].”

Roles and Coordination

Incident Commander

The incident commander (IC) owns the incident process — coordinating communication, delegating investigation tasks, and making decisions about escalation and resolution.

“I’m taking IC. I need someone to own the database investigation and someone to handle stakeholder communications. Who can take each?” “As IC, I’m making the call to roll back. We don’t have enough information to push forward safely.”

Scribe

The scribe documents what is happening in real time — tracking the timeline, decisions, and action items.

“Can someone take the scribe role? I need a running log of what we’re trying and what we’re finding.”

Delegating Tasks Clearly

During an incident, ambiguous task assignments cause delays. Be explicit.

“[Name], can you own the database investigation and report back in ten minutes?” “[Name], please draft a customer-facing status page update and post it once I’ve approved it.” “I need someone to check whether the CDN config changed in the last two hours. Who can take that?”

Resolving the Incident

Declaring Resolution

“The service is back to baseline. I’m declaring the incident resolved at 16:07 UTC.” “Error rates have returned to normal. We’ll keep monitoring for the next thirty minutes before formally closing the incident.” “The rollback is complete. Traffic is recovering. All-clear in approximately five minutes.”

Post-Incident Handoff

“The incident is resolved. Please join #incident-review for the post-mortem. I’ll send a calendar invite for tomorrow.” “We’ll follow up with a blameless post-mortem. Owner for that document is [Name].”

Practical Phrases Reference

Opening:

• “Declaring a SEV-2 incident. War room is open at [link].”

Investigating:

• “We’re investigating — no root cause confirmed yet.”
• “We’ve reproduced the issue in staging and are working on a fix.”

Mitigating:

• “Partial mitigation in place. Monitoring recovery.”
• “Rolling back now. ETA to recovery: ten minutes.”

Resolving:

• “Service restored. Incident closed at [time] UTC.”
• “Post-mortem to follow within 48 hours.”

Clear communication during an incident does not require perfect English — it requires precise, structured, calm language. The phrases in this guide are used by on-call engineers at companies ranging from two-person startups to hyperscale cloud providers. Practise them before you need them.