Skip to main content

Service outage email templates: telling customers it is down, and when it is back

Seven outage emails for a software product, from the first notice to the post-mortem. Each one says what is broken in plain words and promises only what you can keep: the time of the next update.

The templates

Each one copies with its subject line. The parts in brackets are the parts to change; everything else can go out as written. They work whatever you call it: an outage, a service disruption or a service interruption.

First notice, while it is down

Subject: [Product] is down: [what is not working]

Hi [Name], [Product] is having an outage right now. Since [time and time zone], [what is not working, in plain words, for example: sync is failing, so changes made on one device are not reaching the others]. What still works: [what is unaffected, for example: the app itself, and everything already on your Mac]. [Only if you know it for certain: Your data is safe; nothing has been lost.] I am working on it now. I do not know yet how long the fix will take, so rather than guess, I will send the next update by [time and time zone], whether or not it is fixed by then. [If you have one: You can follow it live at status page link.] Sorry for the disruption. [Your name]
Progress update, still down

Subject: Outage update: [what is affected] ([time and time zone])

Hi [Name], An update on the outage, as promised. [Product] is still [down / partly working]: [what is still affected]. What I know now: [one or two plain sentences, for example: the cause is a database update that failed on our server, and I am rolling it back]. [If anything has changed for them: Sync is working again for most accounts. If yours is not, quitting and reopening the app should pick it up.] Next update by [time and time zone], or sooner if it is fixed. [Your name]
All clear, it is working again

Subject: Resolved: [Product] is working again

Hi [Name], [Product] is working again. The outage lasted from [start time] to [end time, time zone], and [what was affected] is back to normal. [What they need to do: Nothing on your side. / Quit and reopen the app once. / Changes you made while it was down were saved and will sync in the next few minutes.] [One honest sentence on the cause, if you know it.] I will send a short write-up [in the next few days / by date] on what happened and what I am changing because of it. Sorry for the disruption, and thank you for your patience while it was down. [Your name]
The post-mortem, for customers

Subject: What happened during the [Product] outage on [date]

Hi [Name], On [date], [Product] was [down / partly down] for [duration], from [start time] to [end time, time zone]. Here is what happened, in plain terms. What you would have seen: [the symptom from the customer's side, for example: the app could not sync, and new sign-ins failed]. What caused it: [the cause in one or two sentences, without jargon]. Why it took [duration] to fix: [one honest sentence, for example: the first fix I tried made it worse, and I had to undo it before trying again]. What I am changing: [one to three concrete changes, for example: a backup server that takes over on its own, and an alert that reaches my phone within a minute]. [About data: No data was lost. / Changes made between start time and end time were lost; if you were affected, I will contact you directly.] If the outage cost you something, or affected you in a way this does not describe, reply to this email. It comes straight to me, and I will look at your account personally. [Your name]
Partial outage: one feature, or some customers

Subject: [Feature] is not working in [Product] right now

Hi [Name], A heads-up: [feature] in [Product] is not working right now, since about [time and time zone]. [Who and what is affected, for example: It only affects imports; everything else is working normally.] If you need [feature] before it is back, [workaround, for example: the web version can still export in the meantime]. Otherwise there is nothing to do. [Only if you know it for certain: Nothing you have already saved is affected.] Next update by [time and time zone]. [Your name]
Short reply to someone who writes in while it is down

Subject: Re: [their subject line]

Hi [Name], It is not you: [Product] is having an outage, and I am working on it now. I will reply here as soon as it is fixed. [If you have one: Live updates are at status page link.] [Your name]
Personal note once it is fixed, to someone who wrote in

Subject: Re: [their subject line]

Hi [Name], As promised: it is fixed. [Product] had an outage [this morning / on date], and [what they reported] was part of it. Everything has been working normally since [time and time zone]. [What they need to do, if anything, for example: If the export you started failed, running it again will work now.] Thank you for writing in. Your email helped me see how far the problem reached, and I am sorry it got in the way of your [day / work]. [Your name]

If the downtime is planned rather than a surprise, the scheduled maintenance email templates cover the advance notice, the reminder and the maintenance that runs over.

Subject lines for each stage

Put the state in the subject (down, update, resolved) and keep the rest of the wording the same across the sequence, so the emails read as one story in the inbox. Avoid anything that could pass for a security notice: “Important information about your account” gets ignored, or reported.

  • [Product] is down: [what is not working]
  • Outage update: [what is affected] ([time and time zone])
  • Resolved: [Product] is working again
  • What happened during the [Product] outage on [date]
  • Re: [their subject line] (for anyone who wrote in)

What makes an outage email land

  • Plain words for what is broken. “Sync is failing” beats “degraded performance”. The customer already knows something is wrong; they want to know whether it is the thing they are seeing.
  • Say what still works. It is often the bigger relief: the app runs, the files are there, only sync is down. It also stops people trying fixes on their side that cannot help.
  • A time for the next update, then keep it. “Next update by 3pm UK time” is a promise you control. Sending “no change yet, still on it” at 3pm is what makes people believe the next email.
  • No fix time you do not know. “Back within the hour” that turns into four hours costs more trust than the outage did. If you do know, say it, with the time zone.
  • One place to check. A status page link turns “is it still down?” emails into a page people refresh. Keep it in step with the emails, so the two never disagree.
  • Data, only when you are sure. “Nothing has been lost” is the sentence customers most want to read, which is exactly why it goes in only when you know it is true.

What not to write:

  • “We apologise for any inconvenience.” Say sorry for the specific thing it stopped them doing.
  • “Some users may be experiencing issues.” If you are writing to them, they are.
  • “Our team is working hard on a fix.” If the team is you, say “I am working on it”. People are kinder to a person than to a team they cannot see.

The broadcast goes to everyone. The replies go to one person each

Moorline does not send outage notices; your status page, or whatever you already send product email with, does that. It is for the other half. While the service is down, customers write in, and each one gets a quick “it is on our side, I will tell you when it is fixed”. That is a promise, made separately to every one of them, and the all-clear sent to everyone does not keep it. They are waiting for an answer in their own thread.

In Moorline, every conversation carries two facts: is the work handled, and has the customer been told. When the fix lands, the first is true for all of them at once; every one where the second is not stays on your list as a reply owed until you have written back. The holding reply and the personal note above belong in snippets one shortcut away (⌘;), with the customer’s first name filled in. The model behind it is in how to never forget to reply to a customer, with or without software.

Questions people ask

What should a service disruption email include?

What is not working, since when, what still works, whether data is affected (only if you know), the time of the next update, and a link to a status page if you have one. Leave out a fix time unless you are sure of it, and leave out the technical cause until you understand it.

How often should I send updates during an outage?

At the interval you promise in the first email, and never later than that. For a full outage, roughly every hour is a sensible rhythm; for a partial one affecting a single feature, every few hours is fine. The interval matters less than keeping it: an update at the promised time that says "still working on it" does more for trust than silence followed by good news.

Should I email customers about every outage?

No. A few minutes of downtime that almost nobody noticed belongs on a status page, not in every customer’s inbox. Email when customers were likely to notice: a long outage, a failure they could not work around, or anything that touched their data. For a partial outage, email only the accounts that were affected.

How do I apologise for an outage without over-apologising?

Once per email, specifically, near the end: "sorry, I know this stopped you sending invoices this morning" says more than "we apologise for any inconvenience". Save the fuller apology for the post-mortem, where it sits beside what you are changing, which is the part that makes an apology believable.

Should I offer a credit or a refund after an outage?

It depends on how long it lasted, what it cost your customers, and any uptime promise you have made. For a short outage, a clear explanation is usually enough. When you do offer a credit, say how much, and apply it yourself rather than asking people to write in and claim it.