An outage communication template is a pre-written notice with blanks for the facts that change: what broke, who it affects, since when, and when you will say more. Below are 9 outage notification templates you can copy today, grouped by channel and audience: internal IT emails to employees, customer-facing outage emails, a planned maintenance notice, four status page blocks, a Slack or Teams message, and a 160-character SMS.

Every template uses {{placeholders}} so you can drop it into your email tool, your incident runbook, or your status page and fill in the blanks under pressure. Before the templates you will find a checklist of what each notice must contain and how often to send it, and after them the five mistakes I see most often in outage emails.

Quick summary

  • Every outage notification needs 6 fields: what, who is affected, since when, workaround, next update time, and where to follow.
  • Send the first notice within 15 to 30 minutes of confirming the outage, even without a cause or an ETA.
  • Send updates every 30 to 60 minutes while the outage is open, and every 15 minutes for a full outage of a revenue-critical service.
  • An SMS alert must stay under 160 characters to arrive as one segment.
  • Send the planned maintenance notice about 7 days ahead, a reminder 24 hours before, and a completion notice at the end.

What every outage notification must contain

I keep the checklist to six fields. If a draft is missing any of them, it is not ready to send, and if you cannot fill one yet, write "not yet known" rather than dropping the line.

Field Question it answers Example
What Which service or function is broken, and how "Checkout API returning 502 errors"
Who is affected Which customers, teams, regions or plans "All customers on EU data centers"
Since when Start time with an explicit timezone "Since 09:14 UTC"
Workaround What people can do in the meantime, or "none for now" "The mobile app is unaffected"
Next update time When they will hear from you again "Next update by 10:00 UTC"
Where to follow One link for live status, so nobody has to ask "status.example.com"

Root cause and ETA are absent on purpose. Both are useful when you have them, but waiting for either before sending the first notice is the most common reason outage communication arrives late.

When to send outage notifications and how often

Timing matters as much as wording. The schedule below is what I recommend to teams setting up their first incident management process, and every template further down assumes it.

Moment What to send Channels
Within 15 to 30 min of confirming the outage First notice with the six fields, no cause needed Status page, Slack/Teams, email for major outages
Every 30 to 60 min while open (15 min for a full outage) Update, even if it says "no change, still working on it" Status page, internal channel, email if the ETA moved
As soon as an ETA changes Revised estimate with the reason it moved Same channels as the first notice
Within 30 min of the fix Resolved notice with duration and next steps Every channel that received the first notice
Within 5 business days Post-incident review link Status page and email

The one rule I would keep above all others: never let a promised update time pass. If you wrote "next update by 10:00" and you have nothing new at 10:00, send "still investigating, next update by 10:30" anyway.

Internal IT outage notification templates for employees

Internal notices have one extra job: stopping duplicate tickets and DMs before they start. Say clearly that IT knows, name the ticket, and tell people where to follow instead of asking.

1. IT outage notification email to employees

Subject: [IT outage] {{system_name}} unavailable since {{start_time}} {{timezone}}

Hi all,

{{system_name}} is currently unavailable. IT is aware and working on it, so there is no need to open a ticket.

What is affected: {{affected_functions, e.g. VPN login, sending email}}
Who is affected: {{teams_or_locations}}
Since: {{start_time}} {{timezone}}
Workaround: {{workaround, or "none for now"}}
Next update: by {{next_update_time}} {{timezone}}, or sooner if service comes back

We are tracking this as {{ticket_id}}. Live updates are posted in {{channel_or_internal_status_page_url}}.

{{sender_name}}
{{it_team_name}}

2. Internal outage update email

Subject: [IT outage update #{{n}}] {{system_name}}: {{one_line_status}}

Update as of {{time}} {{timezone}}.

Status: {{investigating | cause identified | fix in progress}}
What we know: {{cause_or_what_has_been_ruled_out}}
What we are doing: {{current_action}}
Estimated restore time: {{eta, or "not yet known"}}
Workaround: {{workaround}}

Next update by {{next_update_time}} {{timezone}}. Tracking ticket: {{ticket_id}}.

{{sender_name}}

3. Slack or Teams internal channel message

Post this in the incident channel and keep every follow-up in the thread. Pinning the message saves the on-call engineer from answering the same question ten times.

:red_circle: OUTAGE: {{system_name}} down since {{start_time}} {{timezone}}
Impact: {{who_is_affected}} cannot {{what_they_cannot_do}}
Status: investigating. Incident lead: @{{incident_lead}}
Workaround: {{workaround, or "none for now"}}
Next update in this thread by {{next_update_time}}. Please keep questions in the thread.

Customer-facing outage email templates

Customers care about three things: is it you or me, what can I do right now, and when will I hear from you again. Lead with the symptom they are seeing so they can match it to their own experience.

4. Initial customer outage email

Subject: {{product_name}} service disruption: {{short_description}}

Hi {{first_name}},

Since {{start_time}} {{timezone}}, {{feature_or_service}} is {{unavailable | slow | failing for some requests}}. If you are seeing {{what_the_customer_sees}}, this is the cause and the problem is on our side.

Who is affected: {{customer_segment_or_region}}
What still works: {{unaffected_features}}
Workaround: {{workaround, or "none for now"}}

Our engineers are working on it now. We will send another update by {{next_update_time}} {{timezone}}, and you can follow progress at {{status_page_url}}.

We are sorry for the disruption.

{{sender_name}}
{{title}}, {{company_name}}

5. Customer update with a revised ETA

Subject: Update on the {{product_name}} disruption: new estimate {{new_eta}} {{timezone}}

Hi {{first_name}},

An update on the {{feature_or_service}} disruption that started at {{start_time}} {{timezone}}.

What we found: {{plain_language_cause}}
What we are doing: {{fix_in_progress}}
Revised estimate: we now expect service back by {{new_eta}} {{timezone}}. Our earlier estimate of {{old_eta}} was wrong because {{one_line_reason}}.
Workaround: {{workaround}}

Next update by {{next_update_time}} {{timezone}}, or as soon as service is restored. Live status: {{status_page_url}}.

{{sender_name}}

6. Resolved and apology email

Subject: Resolved: {{product_name}} disruption on {{date}}

Hi {{first_name}},

{{feature_or_service}} has been fully restored as of {{end_time}} {{timezone}}. The outage lasted {{duration}}, from {{start_time}} to {{end_time}} {{timezone}}.

What happened: {{two_sentence_cause}}
What we did: {{fix_applied}}
What you may need to do: {{customer_action, or "nothing"}}
What we are changing: {{prevention_measure}}

We are sorry. {{one_sentence_naming_the_impact_customers_felt}}. A full write-up will be published at {{postmortem_url}} by {{date}}. If you are still seeing problems, reply to this email or contact {{support_channel}}.

{{sender_name}}
{{title}}, {{company_name}}

Planned outage notification template

A planned outage notification differs from an incident notice in one way: you owe people the reason for the downtime and the reason for the window you picked. Send it about 7 days ahead, repeat it 24 hours before with the same subject line prefixed "Reminder:", and close it with a two-line completion notice.

7. Scheduled maintenance notice

Subject: Scheduled maintenance on {{date}}: {{service}} unavailable for up to {{duration}}

Hi {{first_name}},

We will perform scheduled maintenance on {{service}} on {{date}} from {{start_time}} to {{end_time}} {{timezone}}.

Why: {{reason_in_one_line, e.g. database upgrade to a supported version}}
Impact: {{what_will_be_unavailable_or_degraded}}
Expected downtime: up to {{duration}}
What still works: {{unaffected_services}}
What you should do: {{action_before_the_window, or "nothing"}}

We chose this window because {{low_traffic_reason}}. If the date changes, we will notify you at least {{notice_period}} in advance. Progress and completion will be posted at {{status_page_url}}.

{{sender_name}}
{{title}}, {{company_name}}

For the completion notice, two lines are enough: "Maintenance on {{service}} finished at {{end_time}} {{timezone}}, {{minutes}} minutes ahead of schedule. All services are operating normally, contact {{support_channel}} if you notice anything unusual."

Status page incident post templates

Status page posts are shorter than emails because subscribers receive every update. Each block below is one post in the incident timeline, and each one ends with the next update time. If you use status page templates in your tool, these four blocks map to the four standard incident states.

8. Investigating, identified, monitoring, resolved

Investigating, {{time}} {{timezone}}
We are investigating {{symptom}} affecting {{component}}. {{scope, e.g. customers in the EU region}} are impacted. Next update by {{next_update_time}}.
Identified, {{time}} {{timezone}}
The cause is {{plain_language_cause}}. {{scope}} remain affected. A fix is {{being deployed | in progress}} and we expect service back by {{eta, or "we will confirm an estimate in the next update"}}. Next update by {{next_update_time}}.
Monitoring, {{time}} {{timezone}}
A fix has been deployed and {{component}} has been responding normally since {{time}}. We are monitoring for {{duration}} before closing this incident. Next update by {{next_update_time}}.
Resolved, {{time}} {{timezone}}
This incident is resolved. {{component}} was {{unavailable | degraded}} from {{start_time}} to {{end_time}} {{timezone}} ({{duration}}). {{one_line_cause}}. A post-incident review will be published by {{date}}.

SMS outage alert template

SMS is for the people who cannot wait for email: on-call engineers, key account contacts, and customers who subscribed to text alerts. Stay under 160 characters so it arrives as one segment, and put the status link before the next update time so the reader sees where to look before they see when.

9. SMS alert (under 160 characters)

{{company}}: {{service}} outage since {{HH:MM}} {{TZ}}. Affects {{scope}}. Team working on it. Updates: {{short_status_url}}. Next update {{HH:MM}}.

Filled in, it reads: "Acme: API outage since 09:14 UTC. Affects EU customers. Team working on it. Updates: acme.st/x. Next update 10:00." That is 114 characters, which leaves room for a longer service name or scope.

5 outage notification mistakes to avoid

These are the patterns I see most often in the outage emails that land in my own inbox as a customer, and in the ones we reviewed while writing the incident communication templates that cover the wider set of incident types.

  • Waiting for the root cause. The first notice needs the six fields above and nothing else. A team that waits an hour to say "we found the cause" has spent that hour with customers wondering whether the problem is on their side.
  • Vague scope. "Some users may experience issues" tells the reader nothing about whether they are affected. Name the region, plan, feature, or percentage, and if you do not know yet, say "we are still confirming the scope".
  • Missing a promised update. If the notice said "next update by 10:00" and 10:00 passes in silence, every reader assumes things got worse. A one-line "still working on it, next update by 10:30" costs thirty seconds.
  • Hiding behind passive voice and vendors. "An issue was identified" and "our cloud provider experienced a problem" both read as evasion. Write "we deployed a config change that broke login" or "our database host went down and we failed over too slowly", and let the post-incident review carry the vendor detail.
  • Never closing the loop. Every channel that carried the first notice must carry the resolved notice, including the internal email to employees and the SMS list. Support teams in particular need the resolved message with the customer-facing wording so their replies match.

Publish outage updates from a status page

Emails and Slack messages are written per outage. A status page gives customers one place to check and takes the "is it down for everyone?" tickets off your support queue, and subscribers get each incident update pushed to them instead of waiting for your next email. Hyperping sells status pages, so read the next paragraph with that in mind.

On Hyperping, an incident on the status page follows the same four states as template 8, and every published update goes to subscribers by email, Slack, or SMS. Monitors attached to the page can open the incident automatically when a check fails, which covers the first-notice window even at 3 a.m. The free status page plan includes 1 status page and 20 monitors at $0; subscriber notifications and a custom domain start on Essentials at $29 per month ($24 billed yearly).

If you would rather write your own status page copy first, the 10 status page templates for incident management cover degradation, security, third-party and partial outage cases with wording ready to adapt.