Outage notification template

An outage notification tells customers that a service they rely on is disrupted, what is affected and what your team is doing about it. It usually takes two forms: a notice on your status page, updated as the incident progresses, and an email to the customers who are affected.

It is a public message. Internal details, such as the suspected change, who is on call or the theory the team is testing, stay in the incident channel and the incident report. The notification says only what customers need to decide what to do next.

The same messages are often called incident communication: the set of updates an incident produces, from the first acknowledgment to resolution.

Status pages move an incident through four stages. Each tells customers something different, and each update replaces the last.

Not every incident passes through all four. A quick rollback can go straight from Investigating to Monitoring. Skip a stage rather than post an update that says nothing new.

The service status says how much of the service customers can use. It matches the component status on your status page, so the notice and the page agree.

• Degraded. The service works, but badly: slow responses, intermittent errors, delayed processing.
• Partial outage. Part of the service doesn't work for some users: a feature, a region or a group of accounts.
• Unavailable. The service can't be used at all.

Describe the impact with the service status, not your internal severity. Severity is how your team decides how urgently to respond and who to page. To a customer, "SEV-2" means nothing, and it can mislead: an incident that is critical for one large account may be a partial outage for everyone else. The service status describes what customers actually experience.

The service status can change during an incident. If a partial outage spreads, update the notice to Unavailable rather than leaving the original status in place.

Post the first notice as soon as customer impact is confirmed, before you know the cause. That is what Investigating is for. Customers who see errors next to an all-green status page assume you don't know, and open support tickets to tell you.

Update the notice each time the incident status or the service status changes. During a long investigation, post an update even when nothing has changed, so the page doesn't look abandoned.

Email the affected customers when the incident starts and when it is resolved. Whether to email at Identified and Monitoring as well depends on how long the incident lasts; for a short one, the status page covers the steps in between.

Status page notice

A notice keeps one title for its whole life. Describe the symptom, not the cause: "Elevated API error rates", not "Database connection pool exhausted". Leave out component names if the list may change, and leave out severity.

Alongside the title: the incident status, the service status, the affected components and when the impact started. Customers use the start time to match the incident against problems they saw, so always show its timezone. The template fills in the current time in yours.

The update itself is one or two sentences: what's affected and what you're doing. Don't speculate about the cause, and don't promise a fix time you can't keep.

Customer email

The subject line carries the message for anyone who doesn't open the email: [incident status] notice title affecting components → service status. For example, "[Investigating] Elevated API error rates affecting API → Partial outage". Customers can filter on it, and a later "[Resolved]" email, without the service status, closes the thread.

The body repeats the status page update word for word, so the facts are the same on every channel, and links to the status page for further updates. Once the incident is resolved, the link is replaced with an invitation to reply with questions.

The following examples continue the INC-2026-017 incident used in the incident report and postmortem templates. About 18% of API requests failed for 28 minutes, while dashboards and the status page kept working: a partial outage.

Notice title: Elevated API error rates Affected components: API Started at: 2026-09-03 14:03 UTC

The same incident as Degraded

If the queries had only slowed the API down instead of failing requests, the service status would be Degraded, and the first update would read:

We're investigating reports of issues affecting some functionality. Users may experience slight delays or intermittent errors.

Customer email

Subject: [Investigating] Elevated API error rates affecting API → Partial outage

Hi Alex,

We're investigating a partial outage. Some features are currently unavailable to some users.

You can follow progress on our status page: status.example.com

We're sorry for the disruption.

The Example team

The notice and the email are written in minutes, for customers, while the incident is still running. The postmortem comes later and explains. The incident report is the internal record behind all three.

• Lead with impact, not cause. Customers need to know what they can't do. The cause can wait for the postmortem.
• Use plain language. Write "some users can't sign in", not "elevated 5xx rates on the auth service".
• Don't speculate. Say you've identified the cause only once you have. Correcting a wrong guess in public costs more trust than waiting.
• Describe impact as service status, and keep severity labels internal. Degraded, partial outage or unavailable tells customers what they're experiencing; SEV levels don't.
• Keep the facts the same on every channel. The status page, the email and what support tells customers should match.
• Don't promise a fix time you can't keep. A missed estimate does more damage than none.
• Close every incident. A notice left in Monitoring for hours makes customers wonder whether it's over.

What should an incident communication template include?

Each update should say what's affected, how badly (degraded, partial outage or unavailable) and what your team is doing, plus when the problem started. Keep each update to one or two sentences, and leave the cause and internal details for the postmortem.

How often should you update customers during an outage?

Whenever the incident status or the service status changes. During a long investigation, also post at a regular interval, such as every 30 or 60 minutes, even when nothing has changed, so customers know the incident hasn't been forgotten.

What is the difference between degraded performance and a partial outage?

With degraded performance, the service still works for everyone, but slowly or with intermittent errors. In a partial outage, part of the service doesn't work at all for some users, such as a feature, a region or a group of accounts.

Should you apologize in an outage notification?

Yes, in the customer email. One sentence such as "We're sorry for the disruption" acknowledges the impact without turning the message into a statement. Status page updates can stay factual.

Decide before the next incident who posts the notice, who sends the email and which customers receive it. Write the wording in advance, as this template does, so the first update goes out within minutes instead of after a debate about phrasing. Record those decisions in your incident response plan.

Done consistently, outage notifications cut the "is it down?" support tickets and keep customers informed through the incidents you can't prevent.

More on incident communication from the StatusPal blog:

• All About Incident Communication: why pre-written templates keep messages fast and consistent, and the first contact, status update and resolution steps this template follows.
• How To Create an Incident Communication Plan: who to tell, through which channels, and why regular updates matter even when nothing has changed.
• Key Learnings from the Facebook Status Page: what goes wrong when a status page shows "healthy" during an outage, or leaves out when the incident started.