Complete Guide to English Incident Communication: From Outage Reports to Postmortem Writing

• Introduction
• Importance of Incident Communication
  • Why Incident English Matters
  • 3-Phase Incident Communication Structure
• English Expressions by Incident Severity
  • Severity Level Classification
  • Core Expressions for Declaring a Severity
• Making the Initial Report
  • Core Phrases for the Initial Report
  • Incident Report Email Template
• Escalation Communication
  • Expressions for Requesting an Escalation
  • What an Escalation Must Always Include
• Real-time Status Updates
  • Expressions for Reporting Progress
  • Recording the Timeline
• Slack and Teams Messages
  • Opening the Incident Channel
  • Slack Message Examples by Situation
  • A Collection of Useful Slack Incident Phrases
• Writing Status Page Updates
  • Principles for Writing a Status Page
  • Status Page Update Templates
  • Status Words Used Most Often on a Status Page
• How to Write the Postmortem
  • The Core Principle of a Blameless Postmortem
  • The Postmortem Document Template
  • Expressions That Recur in a Postmortem
• RCA Report English Expressions
  • The 5 Whys Template
  • English Expressions Used in an RCA Report
• Retrospective Meeting Expressions
  • Opening the Meeting
  • During the Meeting
  • Closing the Meeting
• Common Mistakes and Corrections
  • Corrections Table
  • A Note on Tone
• Production Checklist
  • Incident Communication Checklist
  • Summary of Key English Expressions by Incident Phase
• References

Introduction

It is 3 a.m. and PagerDuty goes off. A production service is down, and the global team's Incident Commander is asking for a status report in the Slack channel. How do you convey in English an outage you could describe perfectly clearly in your own language?

Incident communication is not simply a question of English ability. You need precise terminology, a structured reporting format, and the right expression for each situation. Google's SRE team defines the heart of incident management as the "Three Cs" -- Coordinate, Communicate, Control. Of those three, Communicate is the one that decides whether the response succeeds.

This guide gives you the practical English expressions and templates for every stage of the incident lifecycle, from the moment the outage starts to the finished postmortem. It is built on the incident communication guidelines that PagerDuty, Atlassian, and Google SRE actually use.

Importance of Incident Communication

Why Incident English Matters

An outage is the highest-pressure communication situation a global team faces. Even if your everyday English is fluent, an incident brings its own difficulties.

• Time pressure: you have minutes to convey the situation accurately
• Technical precision: a vague phrase can lead to the wrong response
• Mixed audiences: engineers, managers, executives, and customers each need a different level of explanation
• Documentation requirements: every message becomes evidence in the postmortem later

According to PagerDuty's incident response guidelines, the first external communication must go out within five minutes of the incident call starting. For the first two hours after that, you should post an update at least every 20 minutes.

3-Phase Incident Communication Structure

Atlassian's incident management handbook splits communication into the following three phases.

English Expressions by Incident Severity

Classifying and communicating an incident's severity correctly is the first step in deciding the right level of response.

Severity Level Classification

Core Expressions for Declaring a Severity

# Declaring SEV1
"I'm declaring this a SEV1 incident. We have a complete outage of our payment processing service."
("I'm declaring this a SEV1" is the formal act that starts the response.)

# Declaring SEV2
"This is being escalated to SEV2. We're seeing significant degradation across multiple services."
("Being escalated to SEV2" raises the level without restarting the incident.)

# Raising the severity
"We're upgrading this from SEV3 to SEV2. The blast radius is wider than initially assessed."
("The blast radius is wider than initially assessed" is the standard reason for an upgrade.)

# Lowering the severity
"Based on the reduced impact, we're downgrading this to SEV3."
(Downgrading needs a stated reason, exactly like upgrading does.)

Making the Initial Report

The very first thing to do after an outage begins is to make a fast, structured initial report. Getting out what you do know, even before everything is confirmed, is what matters.

Core Phrases for the Initial Report

# Reporting the detection
"We've detected an anomaly in [service]. [Describe the symptom]."
("Detected an anomaly" claims nothing about the cause.)

"Our monitoring has triggered alerts for [service]. We're seeing [symptom]."
(Attributes the signal to monitoring, which sets the confidence level.)

"We're currently investigating elevated error rates on [service]."
("Elevated error rates" is the neutral, measurable phrasing.)

# Reporting the blast radius
"Impact: Approximately [X]% of users are unable to [action]."
(Puts a percentage on the impact instead of saying "some users.")

"This is affecting all users in the [region] region."
(Bounds the impact geographically.)

"The blast radius includes [service A], [service B], and [service C]."
("Blast radius" is the standard term for the set of things affected.)

# Reporting what you are doing
"We have identified the issue and are working on a fix."
(Says the cause is known and work is underway, in one line.)

"We're actively investigating. No root cause identified yet."
(Honest about not having a cause yet, while showing the work is active.)

"A rollback has been initiated and we expect resolution within [time]."
(Pairs the action taken with an expected resolution time.)

Incident Report Email Template

Subject: [SEV1] Payment Service Outage - Incident #INC-2026-0308

Team,

Incident Summary:
- Incident ID: INC-2026-0308
- Severity: SEV1 (Critical)
- Detected at: 2026-03-08 03:15 UTC
- Incident Commander: Jane Smith
- Status: Investigating

What happened:
At approximately 03:15 UTC, our monitoring detected a complete failure
of the payment processing pipeline. All transaction attempts are
returning 500 errors.

Impact:
- 100% of payment transactions are failing
- Estimated revenue impact: ~$50K/hour
- All regions affected
- Approximately 15,000 users impacted

Current Actions:
- On-call SRE team has been paged and is actively investigating
- Database team has been engaged
- We are examining recent deployment changes as a potential cause

Next Update:
We will provide an update within 30 minutes or sooner if we identify
the root cause.

Incident Channel: #inc-2026-0308-payment-outage

Regards,
[Name]
Incident Commander

Escalation Communication

When an outage exceeds the current team's capacity, or the blast radius widens, escalation is required. Escalating is not a sign of weakness; it is a core tool of effective incident management.

Expressions for Requesting an Escalation

# Technical escalation (pulling in another team)
"We need to escalate this to the database team. The issue appears to
be related to connection pool exhaustion."
(Names the team you need and the hypothesis that points at them.)

# Management escalation (reporting to leadership)
"I'm escalating this to VP-level. The customer impact has exceeded
our SEV1 threshold and we may need to issue a public statement."
(Gives the threshold that was crossed, and what may be needed next.)

# Vendor escalation
"We've exhausted our internal troubleshooting options. I'm opening a
Priority 1 support case with AWS/GCP."
(States that internal options are exhausted before opening a vendor case.)

# Handoff
"I've been on-call for 6 hours and need to hand off IC duties.
Here's the current status summary for the incoming IC."
(Hands off with a reason and a status summary, never bare.)

What an Escalation Must Always Include

Real-time Status Updates

Expressions for Reporting Progress

Regular status updates during a response are what keep the whole team's situational awareness intact.

# Still investigating
"We're still investigating. We've narrowed down the issue to the
caching layer but haven't identified the root cause yet."
("Narrowed down to" reports progress even when the cause is still unknown.)

# Cause found
"Root cause identified: A misconfigured rate limiter is dropping
legitimate traffic. Working on a fix now."
(Leads with the finding, then states the next action.)

# Partial recovery
"Partial mitigation in place. We've rerouted traffic to healthy
instances. 80% of users should now have normal access."
("Partial mitigation in place" plus a percentage keeps expectations honest.)

# Full recovery
"The incident has been fully resolved. All services are operating
normally. We will continue monitoring for the next 2 hours."
(Declares resolution and still commits to a monitoring window.)

# Monitoring
"Fix has been deployed. We're monitoring metrics closely.
No recurrence observed so far."
("No recurrence observed so far" is the careful way to say it is holding.)

Recording the Timeline

The incident timeline is the raw material of the postmortem. Getting into the habit of recording events with exact times matters.

# An example timeline record
03:15 UTC - Monitoring alert triggered for payment-service error rate spike
03:17 UTC - On-call engineer acknowledged the alert
03:22 UTC - Incident declared as SEV1, war room opened
03:30 UTC - Root cause identified: bad config push in payment-gateway
03:35 UTC - Rollback initiated for payment-gateway config
03:42 UTC - Rollback completed, error rates returning to normal
03:55 UTC - All metrics back to baseline, incident marked as resolved
04:00 UTC - Post-incident monitoring period started (2 hours)

Slack and Teams Messages

Incident communication in Slack or Microsoft Teams has to be fast and compact. Many organizations use a process that creates a dedicated incident channel automatically.

Opening the Incident Channel

:rotating_light: INCIDENT DECLARED :rotating_light:

Incident: INC-2026-0308
Severity: SEV1 - Critical
Title: Payment Service Complete Outage

Roles:
- Incident Commander (IC): @jane.smith
- Communications Lead: @bob.lee
- Operations Lead: @alex.chen

Impact: All payment transactions failing globally
Status: Investigating

Ground rules:
- Keep this channel for incident-related discussion only
- Use threads for detailed technical discussions
- IC will post regular status updates every 15 minutes

Next update: 03:45 UTC

Slack Message Examples by Situation

# Status update (in progress)
:mag: UPDATE (03:45 UTC)
Status: Still investigating
- Confirmed: Issue is NOT related to the 02:00 UTC deployment
- Currently examining database connection pool metrics
- @db-team has been engaged
Next update: 04:00 UTC

# When the cause is found
:bulb: ROOT CAUSE IDENTIFIED (04:00 UTC)
The connection pool max size was inadvertently reduced from 100 to 10
in yesterday's config change (PR #4521).
Action: Reverting config change now. ETA for resolution: 15 minutes.

# When mitigation is applied
:yellow_circle: PARTIAL MITIGATION (04:10 UTC)
Config has been reverted. Error rates dropping.
- Payment success rate: 45% -> 92% (recovering)
- Still monitoring for full recovery
- Some queued transactions may need manual processing

# When it is resolved
:white_check_mark: RESOLVED (04:25 UTC)
All services fully restored. Payment success rate back to 99.9%.
- Duration: 1 hour 10 minutes
- Root cause: Config change reducing DB connection pool
- Postmortem will be scheduled within 48 hours
- Monitoring will continue for the next 2 hours

Thank you everyone for the quick response.

A Collection of Useful Slack Incident Phrases

Writing Status Page Updates

The status page is the channel that communicates an outage officially, to external customers and internal stakeholders alike. The key is to keep technical jargon out and describe the impact from the customer's point of view.

Principles for Writing a Status Page

1. Use language the customer understands -- "difficulty processing transactions" rather than "DB connection pool exhaustion"
2. Separate current status, impact, and next action clearly
3. Give an ETA only when you are confident in it
4. If there is no security or data-loss concern, say so explicitly

Status Page Update Templates

=== INVESTIGATING ===
Title: Degraded Performance on Payment Processing

[Posted: March 8, 2026 03:20 UTC]
We are currently investigating reports of failed payment transactions.
Some users may experience errors when attempting to complete purchases.
Our engineering team is actively working to identify and resolve the
issue. We will provide an update within 30 minutes.

No data loss or security concerns have been identified at this time.


=== IDENTIFIED ===
Title: Payment Processing - Root Cause Identified

[Updated: March 8, 2026 04:00 UTC]
We have identified the root cause of the payment processing issues.
A configuration change is being applied to restore normal service.
We expect full resolution within the next 15-20 minutes.

Affected services: Payment processing, order confirmation emails
Unaffected services: User accounts, product browsing, search


=== MONITORING ===
Title: Payment Processing - Fix Applied, Monitoring

[Updated: March 8, 2026 04:15 UTC]
A fix has been applied and payment processing is recovering.
Most users should now be able to complete transactions normally.
We are closely monitoring the situation to ensure stability.

If you experienced a failed transaction, please retry. If the issue
persists, contact support@example.com.


=== RESOLVED ===
Title: Payment Processing - Fully Resolved

[Updated: March 8, 2026 04:30 UTC]
The payment processing issue has been fully resolved. All services
are operating normally.

Duration: Approximately 1 hour 15 minutes (03:15 - 04:30 UTC)

We sincerely apologize for any inconvenience this may have caused.
A detailed analysis of this incident will be conducted to prevent
recurrence.

For any ongoing concerns, please contact support@example.com.

Status Words Used Most Often on a Status Page

How to Write the Postmortem

A postmortem is the structured analysis you run after an incident. Google SRE insists on running it as a "Blameless Postmortem". The key is to find what to improve in the system and the process, not to blame an individual's mistake.

The Core Principle of a Blameless Postmortem

# Blaming phrasing (avoid this)
"John made a mistake and pushed the wrong config."
(Points at a person, which shuts down the honest account of what happened.)

# Blameless phrasing (use this)
"The config deployment process lacked sufficient validation checks,
which allowed an incorrect configuration to reach production."
(Points at the process gap, which is the thing you can actually fix.)

The Postmortem Document Template

A working template based on Google SRE's postmortem template.

# Postmortem: Payment Service Outage

## Incident ID: INC-2026-0308

### Metadata

| Field              | Value                 |
| ------------------ | --------------------- |
| Date               | March 8, 2026         |
| Authors            | Jane Smith, Alex Chen |
| Status             | Complete              |
| Severity           | SEV1                  |
| Duration           | 1 hour 10 minutes     |
| Incident Commander | Jane Smith            |

---

### Executive Summary

On March 8, 2026, from 03:15 to 04:25 UTC, users experienced a
complete inability to process payments. The root cause was a
configuration change that reduced the database connection pool
from 100 to 10 connections, causing connection exhaustion under
normal load. Approximately 15,000 users were affected, with an
estimated revenue impact of ~$60,000.

---

### Impact

- **Duration**: 1 hour 10 minutes (03:15 - 04:25 UTC)
- **Users affected**: ~15,000 (100% of payment attempts)
- **Revenue impact**: ~$60,000 estimated
- **Support tickets**: 342 tickets opened
- **SLA impact**: Monthly uptime dropped from 99.95% to 99.87%

---

### Timeline (all times UTC)

| Time  | Event                                                      |
| ----- | ---------------------------------------------------------- |
| 02:00 | Config change deployed via PR #4521 (unrelated to payment) |
| 03:15 | Payment error rate alert triggered (threshold: >1%)        |
| 03:17 | On-call SRE acknowledged alert                             |
| 03:22 | SEV1 declared, incident channel created                    |
| 03:25 | Initial status page update posted                          |
| 03:30 | DB team engaged, connection pool exhaustion identified     |
| 03:35 | Root cause confirmed: PR #4521 reduced pool size           |
| 03:38 | Config rollback initiated                                  |
| 03:42 | Rollback completed                                         |
| 03:55 | Error rates returned to baseline                           |
| 04:00 | Status page updated: monitoring                            |
| 04:25 | Incident resolved, all metrics nominal for 30 minutes      |

---

### Root Cause

PR #4521, intended to update logging configuration, inadvertently
modified the database connection pool size parameter from 100 to 10.
The change passed code review because the pool size parameter was
in the same configuration file as logging settings. Under normal
traffic load (~80 concurrent connections), the reduced pool caused
connection exhaustion, resulting in 500 errors for all payment
requests.

---

### What Went Well

- Alert fired within 2 minutes of impact starting
- On-call engineer responded within 2 minutes
- Incident was declared and war room opened within 7 minutes
- Clear communication maintained throughout

### What Went Poorly

- Config change was not caught in code review
- No automated validation for critical infrastructure parameters
- Rollback took 7 minutes due to manual approval process
- Payment service had no circuit breaker for DB connections

### Where We Got Lucky

- The incident occurred during low-traffic hours (UTC night)
- No data corruption occurred despite connection failures
- A team member happened to be online and recognized the
  config change immediately

---

### Action Items

| ID  | Action                                                  | Type     | Owner | Priority | Due Date |
| --- | ------------------------------------------------------- | -------- | ----- | -------- | -------- |
| 1   | Separate infrastructure config from application config  | Prevent  | @alex | P1       | March 15 |
| 2   | Add automated validation for connection pool parameters | Prevent  | @alex | P1       | March 15 |
| 3   | Implement circuit breaker pattern for DB connections    | Mitigate | @bob  | P2       | March 22 |
| 4   | Add connection pool size to deployment canary checks    | Detect   | @jane | P1       | March 18 |
| 5   | Automate rollback process for config changes            | Mitigate | @ops  | P2       | March 29 |
| 6   | Add runbook for payment service connection failures     | Process  | @jane | P3       | April 5  |

---

### Lessons Learned

Infrastructure-critical parameters should be managed separately
from application-level configuration and require additional
validation gates before deployment.

Expressions That Recur in a Postmortem

# Explaining the cause
"The root cause was determined to be..."
(The standard passive form for stating a confirmed root cause.)

"Contributing factors included..."
("Contributing factors" covers what made it worse without being the cause.)

"The issue was exacerbated by..."
("Exacerbated by" names an aggravating factor precisely.)

# Explaining the impact
"This resulted in a total of [X] minutes of downtime."
(Puts a number on the downtime.)

"The blast radius was limited to [service or region]."
("Limited to" bounds the impact explicitly.)

"User-facing impact lasted approximately [X] minutes."
(Distinguishes user-facing impact from total incident duration.)

# Explaining the action items
"To prevent recurrence, we will implement..."
("To prevent recurrence, we will implement" is the standard commitment form.)

"As a short-term mitigation, we have..."
(Separates the short-term mitigation from the permanent fix.)

"Long-term, we plan to redesign the [system] to..."
(Signals the structural change without promising a date you cannot keep.)

RCA Report English Expressions

Root cause analysis is the core component of a postmortem. The most widely used technique is the 5 Whys.

The 5 Whys Template

# 5 Whys Analysis - Payment Service Outage (INC-2026-0308)

Problem Statement:
Payment service experienced a complete outage for 70 minutes.
(State the problem as an observable fact with a duration attached.)

Why 1: Why did the payment service go down?
-> Database connection pool was exhausted, causing all payment
   requests to fail with timeout errors.
(Each Why answers the previous one with a mechanism, not a person.)

Why 2: Why was the connection pool exhausted?
-> The maximum pool size was reduced from 100 to 10, which is
   insufficient for normal production traffic.
(The answer names the exact number that was wrong.)

Why 3: Why was the pool size reduced?
-> A configuration change in PR #4521 unintentionally modified the
   pool size parameter alongside logging configuration changes.
(The answer moves from the parameter to the change that set it.)

Why 4: Why wasn't this caught during code review?
-> The pool size parameter was co-located with logging config in
   a single file, making it easy to overlook. The reviewer focused
   on the logging changes and missed the pool size modification.
(The answer moves from the change to the review that missed it.)

Why 5: Why was there no automated validation for critical parameters?
-> Our CI/CD pipeline does not include infrastructure parameter
   validation. Configuration changes follow the same review process
   as application code without additional safeguards.
(The final Why lands on the missing safeguard, which is the systemic cause.)

Root Cause:
Lack of separation between infrastructure-critical configuration
and application-level configuration, combined with absence of
automated validation for production-critical parameters.

(The root cause statement names two systemic gaps, not one event.)

English Expressions Used in an RCA Report

Retrospective Meeting Expressions

Once the postmortem document is written, you run a review meeting with the whole team. That meeting has to stay blameless and keep the focus on learning.

Opening the Meeting

# The opening
"Thank you all for joining this postmortem review for INC-2026-0308.
Before we begin, I want to emphasize that this is a blameless
postmortem. We're here to learn from the incident and improve our
systems, not to assign blame."
(Stating the blameless rule out loud, at the top, is what makes people speak freely.)

# Setting the background
"Let me walk you through the timeline of events."
("Walk you through the timeline" starts the chronological account.)

"Here's what we know about the sequence of events."
("Here's what we know" leaves room for what is still unknown.)

During the Meeting

# Asking for more detail
"Can you elaborate on what you observed at that point?"
("Can you elaborate on what you observed" asks for facts, not justification.)

"What information did you have available when you made that decision?"
(Asking what information they had is the blameless way to examine a decision.)

# Discussing improvements
"What could we have done differently to detect this sooner?"
("What could we have done differently" makes detection the subject, not a person.)

"Are there any systemic improvements we should consider?"
("Systemic improvements" pushes the discussion up from the single incident.)

"What guardrails can we put in place to prevent this class of issues?"
("This class of issues" widens the fix beyond this one bug.)

# Locking down action items
"Let's make sure each action item has a clear owner and due date."
(Owner and due date, or the action item will not happen.)

"Who would like to own this action item?"
(Asking for a volunteer beats assigning in the room.)

Closing the Meeting

# Summary and close
"To summarize, we've identified [X] action items. Let me read them
back to confirm alignment."
(Reading the items back is the cheapest way to catch a misunderstanding.)

"Does anyone have any additional observations or concerns before
we close out this postmortem?"
(The last call for concerns, before the document is frozen.)

"The postmortem document will be shared in [location] by end of day.
Please review and add any comments within the next 48 hours."
(Sets both the share time and the comment window.)

Common Mistakes and Corrections

Here are the mistakes Korean speakers make most often in English incident communication, alongside the correct expressions.

Corrections Table

A Note on Tone

# Too casual (avoid this)
"Hey guys, looks like something broke in prod. Looking into it."

# The right professional tone (use this)
"Team, we're investigating an issue affecting production services.
Will provide an update within 15 minutes."

# Too technical for a customer (avoid this externally)
"A null pointer exception in the payment microservice's gRPC handler
caused a cascading failure across the service mesh."

# The right tone for a customer
"We identified a technical issue in our payment processing system
that caused some transactions to fail. The issue has been resolved."

Production Checklist

A communication checklist you can pull up fast when an incident starts.

Incident Communication Checklist

INCIDENT COMMUNICATION CHECKLIST
=================================

[ ] DETECTION
    - Acknowledge the alert within 5 minutes
    - Assess initial severity level
    - Create incident channel (if SEV1/SEV2)

[ ] INITIAL RESPONSE
    - Declare the incident and assign roles
      - Incident Commander (IC)
      - Communications Lead
      - Operations Lead
    - Send initial notification within 5 minutes
    - Post first status page update

[ ] DURING INCIDENT
    - Provide updates every 15-20 minutes
    - Update status page at each phase change
    - Escalate if needed (technical or management)
    - Document all actions in the timeline

[ ] RESOLUTION
    - Confirm all services restored
    - Post final status page update
    - Send resolution notification to stakeholders
    - Begin post-incident monitoring period

[ ] POST-INCIDENT
    - Schedule postmortem within 48 hours
    - Complete postmortem document
    - Conduct postmortem review meeting
    - Track action items to completion
    - Share lessons learned broadly

Summary of Key English Expressions by Incident Phase

References

The main sources behind this guide. Each is treated as an industry standard in its corner of incident communication.

1. Google SRE Book - Postmortem Culture: Learning from Failure - the official guide to how Google's SRE team runs postmortems, covering the principles of a blameless culture and providing a postmortem template. https://sre.google/sre-book/postmortem-culture/

2. PagerDuty Incident Response Documentation - PagerDuty's own incident response process, published as open source. Includes role definitions such as Incident Commander and Communications Lead, plus external communication guidelines. https://response.pagerduty.com/

3. Atlassian - Incident Communication Best Practices - Atlassian's best-practice guide to incident communication, covering status page update strategy and customer communication templates. https://www.atlassian.com/incident-management/incident-communication

4. Atlassian - Incident Postmortem Templates - Atlassian's postmortem templates and guide to running the review meeting, usable directly as Confluence templates. https://www.atlassian.com/incident-management/postmortem/templates

5. Google SRE Book - Example Postmortem - a real postmortem example from the Google SRE book, showing the structure and the writing through the Shakespeare Search outage. https://sre.google/sre-book/example-postmortem/

6. PagerDuty - Severity Levels - a guide defining incident severity levels and the response process for each. https://response.pagerduty.com/before/severity_levels/

7. FireHydrant - A Practical Guide to Incident Communication - a practical guide to incident communication, covering internal and external strategy and how to run a status page. https://firehydrant.com/blog/incident-communication/