Incident Communication Templates (Free Copy-Paste Examples for Outages)

Incident Communication Templates (Copy & Paste)

Use these templates during incidents. Replace placeholders like [service], [impact], and [time].

Industry research on incident response consistently finds that communication lag — the gap between detection and first customer-facing update — is one of the strongest drivers of customer frustration during outages. Based on operational experience at StatusPage.me, teams that pre-write template skeletons before incidents occur publish their first update significantly faster than teams that draft from scratch under pressure.

We are investigating an issue affecting [service]. 
Customers may see [impact]. 
Next update by [time].

We have identified the issue affecting [service] and are applying a fix. 
Next update by [time].

🔴 Investigating (Outage)

We are investigating an issue affecting [service or component].
Customers may see [customer impact]. 
We are actively reviewing the cause and will share another update by [time].

Copy

🟡 Identified

We have identified the cause of the issue affecting [service]. 
The problem is related to [brief cause or affected system]. 
We are applying mitigation steps and will share another update by [time].

Copy

🔵 Monitoring

We have applied a fix for the issue affecting [service]. 
Error rates are returning to normal and we are monitoring recovery closely. 
We will confirm full resolution by [time] unless conditions change.

Copy

🟢 Resolved

This incident has been resolved. [Service] has been stable since [time]. 
We will continue to review the cause internally and publish further detail if needed.

Copy

Additional Templates

Partial Outage

We are investigating a partial outage affecting [service]. 
Some customers may be unable to [task], while other parts of the service remain available.
Next update by [time].

Copy

Degraded Performance

We are investigating degraded performance affecting [service]. 
Customers may see slower responses or intermittent delays, but the service remains available for most requests.
Next update by [time].

Copy

Third-Party Dependency Issue

We are investigating issues affecting [service] caused by an upstream provider problem. 
We are tracking the provider incident and applying mitigation where possible. 
Next update by [time].

Copy

Example Timeline

How to Write Good Incident Updates

• lead with customer impact
• avoid filler like “please bear with us”
• do not speculate on root cause early
• include a next update time
• keep each update short enough to scan quickly

For severity-driven cadence, see Incident severity levels.

How StatusPage.me handles this

Incidents at StatusPage.me are tied directly to your status page, so each update you post in the incident timeline is published to subscribers automatically — email, Slack, and webhook notifications go out without a separate step. You can start an incident from an open monitor alert, which pre-populates the affected component and timestamps the start of the event. The update form keeps things simple: status, message, and the next update time. That structure matches the template pattern above, so your team is not improvising format under pressure.

FAQ

What should every incident update include?

Customer impact, current team action, and the next expected update time.

Should incident updates mention root cause immediately?

Only if the cause is reasonably confirmed. Early updates should focus on impact and response, not speculation.

How long should an incident update be?

Usually one short paragraph is enough. Customers need clarity, not a long internal narrative during the active incident.