Incident Communication Templates: 6 Status Updates You Can Copy

At 3 a.m., with production on fire, nobody writes good prose. That is why the best on-call teams don't write incident updates from scratch: they fill in templates prepared on a calm afternoon.

Below are six templates that cover the whole life of an incident. Copy them into your status page tool and adapt the tone to your brand.

The four rules behind every update

1. Describe symptoms, not guesses. "Some users can't log in" beats "possible Redis failover issue".
2. Say who is affected. All users? EU customers? Only API calls to one endpoint?
3. Say what you're doing. Even "we're investigating" is better than silence.
4. Promise the next update. "Next update in 30 minutes", then keep that promise, even if nothing has changed.

1. Investigating

Title: Elevated errors on [component]

We're investigating reports of [symptom, e.g. failed logins] affecting [scope, e.g. some users in Europe]. Our team is on it. We'll post another update within 30 minutes.

Publish this one fast. The first update matters more than the perfect one.

2. Identified

We've identified the cause: [plain-language explanation, e.g. a faulty configuration change to our authentication service]. We're rolling out a fix now. [Workaround, if any.] Next update by [time, timezone].

3. Monitoring

A fix has been deployed and [component] is recovering. Error rates are back to normal levels. We're monitoring closely to make sure the issue doesn't return.

4. Resolved

This incident is resolved. Between [start time] and [end time] [timezone], [what happened to users]. All systems are operating normally. We're sorry for the disruption; a short summary of what we're changing will follow.

5. Scheduled maintenance

Title: Scheduled database maintenance

On [date] from [start] to [end] [timezone], we'll upgrade [component]. During this window [expected impact, e.g. the dashboard will be read-only for up to 10 minutes]. No action is needed on your side.

Send it at least 48 hours in advance, plus a reminder shortly before it starts. Offer a calendar file so customers can add the window to their own calendars.

6. Postmortem summary

What happened: [one paragraph, customer-facing].
Impact: [duration, % of requests or users affected].
Root cause: [plain language, no blame].
What we're changing: [2–3 concrete follow-up actions].

Customers don't need your internal incident doc. They need proof that the same thing is less likely to happen again.

How often to update

A good rule of thumb:

• Major outage: every 15–30 minutes.
• Partial outage or degradation: every 30–60 minutes.
• Minor issue: on every status change.

Automate the boring part

Templates work best when the tool fills them in for you. In Statusmate, you save incident and maintenance templates once and reuse them from the editor. The same templates are used when an incident opens automatically, so a failing uptime check, or an alert from Grafana, Prometheus Alertmanager or PagerDuty, posts a well-written first update before a human has even opened a laptop. When the alert clears, the incident resolves on its own.

Subscribers receive every update by email, webhook, Telegram or RSS. Maintenance windows get automatic reminder emails and an "Add to calendar" link.

Set up your status page with ready-made templates →