Incident Communication Templates: Exactly What to Say at Each Stage of an Outage

Under incident pressure, blank status page fields cost you minutes you do not have. Communication during an outage is trust preservation. Customers decide whether you are competent and honest long before they care about your internal root cause debate.

The rule that holds across stages is simple. Communicate early and often, including when you have nothing new. A scheduled "no change yet" update beats a ninety-minute silence.

This post is the language itself. Strategy lives elsewhere. Below are eight templates you can paste, fill, and publish.

Cardinal rules

• Say what is affected in customer language (login, checkout, API), not only internal service names.
• Say what you know, then stop. Do not speculate about root cause in public.
• Give the time of the next update. Keep that promise.
• Prefer UTC or a clearly labeled local time and stay consistent.
• Update on cadence during long incidents even when the status is unchanged.

What to avoid

• "We apologize for any inconvenience." It is empty and reads like a script.
• Exact recovery times you cannot defend. Use ranges or "next update by," not false precision.
• Jargon customers cannot act on ("shard election," "pod crashloop") unless your audience is purely technical and expects it.
• Blame aimed at a vendor in the first updates. Stick to impact and status until you have facts worth sharing.

1. Investigating

When. You know something is wrong. Cause is not identified yet.

Template.

We are investigating an issue affecting [product/area]. Some customers may see [symptom in plain language].

We first detected the issue at [time, timezone]. Our team is actively investigating.

Next update by [time, timezone].

Fill-in notes. Name the symptom customers can recognize. Skip guesses about cause. Always include the next update time.

Common mistake. Waiting for a root cause before the first post. The first post exists to show you noticed.

2. Identified

When. You know what is causing the incident and are working on a fix.

Template.

We have identified the cause of the issue affecting [product/area]. [One plain-language sentence about the cause, no unnecessary detail.]

We are [rolling back a change / applying a fix / failing over / other concrete action]. [Product/area] remains [fully unavailable / partially degraded].

Next update by [time, timezone].

Fill-in notes. One sentence of cause is enough for most audiences. Focus on the action underway and current customer impact.

Common mistake. Over-explaining internals. "A bad config shipped in the billing worker" is enough. A paragraph on cache invalidation is not.

3. Fix deployed, monitoring

When. The fix is in. You are watching recovery.

Template.

A fix for the issue affecting [product/area] has been deployed. We are monitoring recovery.

Customers may still see [residual symptom] for a short period while systems normalize.

Next update by [time, timezone], or sooner if status changes.

Fill-in notes. Set expectations for residual errors or cache delay. Do not mark resolved yet.

Common mistake. Declaring victory the second the deploy finishes. Monitoring is its own stage.

4. Resolved

When. Service has recovered and you are closing the incident for customers.

Template.

The issue affecting [product/area] is resolved as of [time, timezone].

Impact lasted from approximately [start] to [end]. During that window, customers may have experienced [brief impact summary].

We will publish a short summary of the cause and follow-ups within [timeframe, e.g. 72 hours].

Fill-in notes. Give a clean end time and a commitment to a fuller summary. Keep the resolved note short.

Common mistake. A long technical essay in the resolved update. Save depth for the post-incident summary.

5. Extended outage update

When. You have been investigating for two or more hours and status has not changed. Customers still need a pulse.

Template.

We are still working on the issue affecting [product/area]. Customer impact remains [same as last update / updated description].

Since our last update we have [actions taken], and we are currently focused on [current focus].

We do not yet have a confirmed recovery time. Next update by [time, timezone].

Fill-in notes. Prove progress without inventing an ETA. "No change in impact" is acceptable if you say what you tried.

Common mistake. Going quiet because there is "nothing new." The update is the product.

6. Scheduled maintenance

When. Planned work that will cause downtime or degradation.

Template.

We will perform scheduled maintenance on [product/area] on [date] from [start time] to [end time] [timezone].

During this window, customers should expect [downtime / read-only / elevated errors].

We will post here if the window changes. Maintenance updates will appear on this page.

Fill-in notes. Publish early enough that people can plan. State the impact bluntly.

Common mistake. Softening planned downtime into "possible brief interruptions" when you know the service will be hard down.

7. Post-incident summary

When. After resolution. Customer-facing version of the postmortem, not the full internal doc.

Template.

On [date], [product/area] experienced an incident from [start] to [end] [timezone]. Customers saw [impact].

Cause. [Two to four sentences in plain language.]

What we are changing. [Two to four concrete follow-ups.]

We apologize for the disruption and appreciate your patience while we worked through it.

Fill-in notes. Specific follow-ups beat vague promises. A short apology tied to the real impact is fine here. The empty "any inconvenience" line still is not.

Common mistake. Copy-pasting the internal postmortem with jargon and unfinished action items.

8. Proactive communication

When. You caught an issue before customers widely reported it, or you see elevated risk.

Template.

We detected [degraded performance / intermittent errors] affecting [product/area] beginning around [time, timezone]. We are investigating and will mitigate before impact spreads if possible.

If you are seeing [symptom], it is related to this issue.

Next update by [time, timezone].

Fill-in notes. Proactive posts buy trust. Say you found it first when that is true.

Common mistake. Waiting for ticket volume before telling the truth you already know.

Keep the templates where you publish

Store these as saved messages on your status page so the first update takes two minutes, not twenty. In Vigiles, status page templates can be pre-written and published when an incident opens, which is the whole point of having the wording ready before the next outage starts.