Outage Email Templates: 5 Stages to Copy and Send
Outage Email Templates: 5 Stages to Copy and Send ! Support lead drafting an outage update When something breaks, you do not need one outage email.
When something breaks, you do not need one outage email. You need five short ones: investigating, cause identified, mitigation, restored, and follow-up. Each says only what you know at that moment, and each leaves unknown fields honestly blank. Below are copy-ready templates for each stage, the rules that make them work, and a way to send them from a shared support inbox without agents contradicting each other.
TL;DR
- Send the first email as soon as you know customers are affected. Do not wait for a cause or a recovery estimate.
- Write one template per stage (investigating, identified, mitigating, restored, follow-up) instead of one generic message.
- Every email names the affected feature, the customer impact, the start time, any workaround, and the exact time of your next update.
- Link every email to one status page or incident post, and tag every related support conversation with one incident ID.
- Say “no action needed” when that is true. Skip reassurance and marketing language.
Table of Contents
- What a good outage email contains
- Before you write: set the ground rules
- The five outage email templates
- Planned maintenance: a sixth, simpler template
- Subject lines that get opened
- Wording rules that hold up under pressure
- Sending outage emails from a shared inbox
- Our perspective: practice before you need it
- Run your outage replies from one shared inbox
- FAQ
- Sources
What a good outage email contains
US cybersecurity agencies have published guidance on exactly this problem. CISA and partner agencies’ September 2026 guidance says an outage communication plan should define notification triggers, escalation paths, responsible roles and ready-to-use templates. Its core message is practical: share operational facts, not PR comfort.
For the first customer email, that translates into six fields:
- What is affected: the product or feature, named the way customers know it (“sending invoices,” not “the billing microservice”).
- Customer-visible impact: what they will see or fail to do.
- When it started: the start time, or the time you discovered it, with a time zone.
- What still works: so people can keep working.
- A safe workaround: only if you have verified it.
- When you will write next: an exact time or a condition, not “soon.”
Notice what is missing: the root cause and the ETA. If you do not know them, say so. “We are still investigating, no action is needed on your side, next update by 3:30 p.m. ET” is more trustworthy than a guess you have to retract an hour later.
Before you write: set the ground rules
Templates only help if the process around them is settled before the outage. Spend an hour on these four decisions.
Pick one source of truth
Keep one status page or incident post as the canonical version. Every email, support reply and social post should link back to it rather than creating a competing account. If your email says one thing and your status page says another, customers will believe the more alarming one.
Keep the channel independent from the problem
If your status page runs on the same hosting, CDN or application that just failed, it goes down with everything else. Host it separately where you can, and keep a backup channel such as email or SMS. An outage that also takes down the place where you explain the outage is the worst version of the day.
Name the roles
The CISA guidance describes outage communication as part of incident response, not something support improvises. Engineering supplies verified status. Whoever owns communications sets the wording and the cadence. Legal or compliance weighs in on disclosure risk. Support turns the update into what a customer should actually do. In a five-person company, that may be two people wearing five hats, but write down who approves the text before it goes out.
Decide the update rhythm
Time-stamped updates should keep coming during an active incident even when nothing has changed. “No change since 2:10 p.m. ET, engineers are still working on the database failover, next update 3:00 p.m. ET” is a perfectly good email. Silence is what fuels speculation.
The five outage email templates
Brackets mark the blanks. If you do not know a fact, delete the sentence or write the honest version, as shown. Times should always include a zone (ET, CT, PT), because your customers are rarely all in yours.
Template 1: Investigating
Send this the moment you confirm that customers are affected, even if that is all you know.
Subject: [Product]: investigating issues with [feature]
Hi [first name],
We are investigating a problem with [feature]. Since about [time, zone], some customers may be unable to [specific action].
What still works: [list, or “all other parts of [Product]”].
We do not yet know the cause or when it will be fixed. [Workaround, if verified. Otherwise: “No action is needed on your side right now.”]
Our next update will be at [time, zone], or sooner if something changes. You can follow live status here: [status page link].
[Name], [Company] Support
The subject line carries the product, the feature and the word “investigating.” Someone skimming a crowded inbox should understand the situation without opening the email.
Template 2: Cause identified
Send this when engineering has verified what is wrong, not when someone has a theory.
Subject: [Product]: cause identified for [feature] issue
Hi [first name],
Update as of [time, zone]: we have identified the cause of the problem with [feature]. [One plain sentence, for example: “A change to our [component] caused requests to fail.”]
Impact is unchanged: [what customers see]. [Anything new they should or should not do.]
We are now [applying a fix / rolling back the change]. We do not have a confirmed recovery time yet. Next update by [time, zone]. Status page: [link].
[Name], [Company] Support
Keep the cause to one sentence. The full explanation belongs in the post-incident report, after you have verified it.
Template 3: Mitigation in progress
Use this when a fix is rolling out and you are watching whether it holds.
Subject: [Product]: fix in progress for [feature]
Hi [first name],
As of [time, zone], we have [rolled out a fix / restored capacity] and [feature] is [recovering for some customers / partially working]. You may still see [specific symptom].
[If relevant: “Please avoid [action] for now, as it may slow recovery.” Otherwise: “No action is needed.”]
We are monitoring closely and will confirm when service is fully restored. Next update by [time, zone]. Status page: [link].
[Name], [Company] Support
This is the stage where teams are tempted to write “fixed.” Resist it. The guidance warns against declaring full resolution while monitoring is still detecting failures.
Template 4: Service restored
Subject: [Product]: [feature] is working again
Hi [first name],
[Feature] was restored at [time, zone]. The issue affected [scope, for example “customers sending email between 1:45 p.m. and 3:20 p.m. ET”].
[If verified: “The cause was [one sentence].” Otherwise: “We are still confirming the root cause.”]
What you need to do: [specific action, such as “re-send any messages that failed”] or “Nothing, no action is needed.”
[We will send a written report by [date] / We do not plan a separate report for this incident.] We are sorry for the disruption. Status page: [link].
[Name], [Company] Support
The resolution email should give the restoration time and the affected scope, state the cause only if it is sufficiently verified, name any required customer action, and say whether a report will follow. One short, specific apology is enough. The guidance specifically warns against reputation-management language.
If your outage disrupted appointments or reservations, the tone of this email matters even more, because customers need to know what happened to their booking. This guide to booking confirmation emails that cut calls and no-shows shows how to confirm changes clearly, which is useful when your restoration message has to double as a rebooking notice.
Template 5: Post-incident follow-up
Send this only if you promised it, and by the date you promised.
Subject: [Product]: what happened on [date] and what we are changing
Hi [first name],
Here is the summary of the [date] incident affecting [feature].
Timeline (all times [zone]): [start], [detection], [cause identified], [fix applied], [restored].
Cause: [verified explanation, in plain language].
Who was affected: [scope, with numbers if you have them].
What we are changing: [two or three concrete steps with owners or dates].
If anything on your account still looks wrong, reply to this email and we will look into it.
[Name], [Company]
A short list of real changes beats a paragraph of regret. If you cannot name a change yet, say when you will.
Planned maintenance: a sixth, simpler template
Planned downtime is easier, because you control the timing. Send the notice early enough for customers to plan around it, and repeat it shortly before the window.
Subject: Scheduled maintenance on [date]: [feature] unavailable [time range, zone]
Hi [first name],
On [day, date], from [start] to [end, zone], we will be [doing what]. During that window, [what will not work] and [what will keep working].
If you rely on [feature] during this time, [workaround or advice]. Otherwise no action is needed.
We will confirm when the work is finished. Status page: [link].
State the window in the customer’s most likely time zone, and say plainly what continues to work.
Subject lines that get opened
In an outage, clarity beats cleverness. A few patterns that work:
- Start with the product: “[Product]: investigating login errors.”
- Use a stage word: investigating, identified, monitoring, resolved. Customers learn to read them.
- Say “update” with a time when it is a follow-up: “Update 3:00 p.m. ET: login errors.”
- Avoid alarm words and euphemisms: no “urgent!!” and no “minor hiccup.” Let the facts set the tone.
Support teams that want more phrasing options for everyday scenarios can borrow from our guide to support email templates for small teams, and our piece on fixing support email tone helps when the draft sounds defensive.
Wording rules that hold up under pressure
A good 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. Beyond that structure, a few habits keep the wording honest.
Say what customers can do. If the answer is nothing, say “no action is needed.” It saves a flood of replies asking whether they should do something.
Do not guess. A made-up ETA is a promise you will break. A time for your next update is a promise you can keep.
Use plain words. “Some customers cannot send messages” beats “degraded performance in the delivery pipeline.”
Acknowledge impact once. One sentence, specific to what they lost. Then back to facts.
Avoid blame. Naming a vendor as the cause before you have verified it, or before you have thought about the contract and legal consequences, creates its own incident. This is where your legal or compliance contact earns their keep.
Keep it short. People read outage emails on phones, often while their own customers are asking questions. Five sentences are usually enough.
Sending outage emails from a shared inbox
The template is half the job. The other half is what happens when 200 customers reply “is this fixed yet?” and four support agents each answer in their own words.
A setup that works in a shared support inbox:
- Create one incident identifier, for example INC-2026-10-17, and tag every outage conversation with it. That also makes the final restoration message easy to send to exactly the affected group.
- Write one approved reply per stage and save it where every agent can find it. Agents paste it, add a personal line if useful, and never invent an ETA.
- Assign a single owner for the incident thread who updates the saved reply each time the status changes.
- Add an internal note to the tagged conversations with the current status, so whoever picks up a reply an hour later does not need to ask.
- Pause nonessential automation. A routine auto-reply promising an answer in one business day reads badly in the middle of an outage. Our notes on auto reply best practices cover how to adjust them, and a short, outage-specific auto-response pointing to the status page can replace the default one.
- Route urgent cases separately. Some customers have a deadline, a contract or a regulated process. Our guide to building an email escalation workflow explains how to pull those out of the pile.
If you are also trying to automate the repetitive parts of service operations, this service operations automation checklist for managers is a useful companion for deciding which steps should be scripted and which should stay human.
After the outage, the backlog is the next problem. If replies stacked up while your team was busy, our 30-day plan to clear a support email backlog walks through recovery, and the piece on why support teams miss customer emails explains where messages tend to slip through.
Our perspective: practice before you need it
We built SendSync for small support teams, and the pattern we see is consistent: outage emails fail less because of bad writing than because of bad coordination. Two agents answer the same question differently. Nobody knows who last updated the ETA. The one person who knows the real status is busy fixing the problem.
So we suggest treating the templates as saved replies that live next to your inbox, not as a document in a folder nobody opens. Write the five stages on a quiet afternoon, agree who approves them, and run one fifteen-minute drill. Simulate a fake incident, tag a few test conversations, send the first-stage reply, and see how long it takes. If it takes more than a few minutes, the setup is too heavy.
We also think a shared inbox should be simple enough to use under stress. That means assigning, tagging, internal notes and saved views, without a configuration project standing between you and the customer who needs an answer. The best outage process is the one your team can execute at 2 a.m. with half its members offline.
— Nick
Run your outage replies from one shared inbox
If your support runs through Gmail or Microsoft 365, SendSync connects those mailboxes without DNS changes, so your team can assign, tag, annotate and reply from one place. Plans have unlimited users and no per-seat fees: Founder is 10 USD per month, Starter 30 USD per month, Growth 80 USD per month and Scale 200 USD per month, and every plan starts with a 14-day free trial. You can see the plans and start a trial at SendSync, then load your five outage templates before you need them.
FAQ
How soon should I send the first outage email?
As soon as you have confirmed customers are affected. You do not need the cause or an ETA, and the CISA guidance says not to delay the first notice until you have them. State what is affected, what customers see and when you will update next.
Should I email every customer or only affected ones?
Email the affected group where you can identify it, and publish the same facts on your status page for everyone else. Tagging conversations with one incident ID helps you reach the right people with the restoration message. If you cannot tell who was affected, a broader notice with a clear “no action needed” line is better than silence.
What if I do not know the cause or the recovery time?
Say so, and give the time of your next update instead. A line such as “We are still investigating, no action is needed, next update at [time]” is more credible than a guess you later correct. Fill in the cause only once it has been verified.
Do I need to send updates when nothing has changed?
Yes. Time-stamped updates at the cadence you promised keep customers from speculating and from flooding your inbox. A two-sentence “no change, still working on it, next update at [time]” is enough.
When is an outage really resolved?
When service is restored and monitoring is no longer detecting failures. Declaring victory early and then reopening the incident costs more trust than waiting another 15 minutes. Send the restoration email with the time, the scope and any action customers must take.
Sources
- CISA and partner agencies, joint guidance on communicating under pressure (September 2026)
- Hyperping, Outage Notification Templates: 9 Copy-Paste Examples (August 2026)