Incident Communication Templates

The best incident communication templates are short, specific, and reusable under pressure. A useful update tells customers what is affected, what you are doing, and when they should expect the next message. It does not try to sound polished. It tries to reduce uncertainty fast.

If you need the product workflow side, see Incident management. This guide gives you copy you can adapt during real incidents.

The minimum structure for every update

Every incident update should answer four things:

• what is happening
• who is affected
• what the team is doing
• when the next update will arrive

Template: investigating

Use this when you have confirmed symptoms but not root cause.

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].

Example:

We are investigating an issue affecting API requests in EU. Some customers may see elevated 500 errors. We are actively reviewing the cause and will share another update by 10:30 UTC.

Template: identified

Use this once the likely cause or failure area is known.

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].

Template: monitoring

Use this when mitigation is in place and recovery is being observed.

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.

Template: resolved

Use this when customer impact has ended.

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.

Template: 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].

Template: 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].

Template: 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].

Practical writing rules

• 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.

Example timeline

FAQ

What should every incident update include?

Every update should 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.