Incident Post-Mortem Email to Customers: 8 Templates

An incident postmortem email to customers has one job: turn an outage your customers already resented into evidence that you are in control. The outage notice told them something broke. The post-mortem tells them why it broke and what is different now.

Below are eight copy-paste templates, from a four-sentence RCA summary to the hard case: the second incident from the same root cause. Every template uses the same placeholders, so you can swap them in without rewriting: [INCIDENT DATE], [DURATION], [ROOT CAUSE], [WHAT CHANGES] and [BY WHEN].

When should you send a post-mortem email to customers?#

Send one when customers could see the problem, not only when your team could. User-visible downtime, any data loss, a long resolution time and a failure that your own monitoring missed are the triggers Google's SRE book lists for writing a post-mortem at all. The customer-facing email is the outward half of that same document.

Skip it for blips nobody noticed. A post-mortem for an incident customers never saw teaches them to worry about things they did not know about. A short note to the few accounts that did notice is enough.

Timing matters more than polish. Once you have confirmed the cause, send. A good post-mortem two weeks late reads as an afterthought, while an honest 'we know the cause, full write-up by [BY WHEN]' note the same week reads as control.

What should a customer-facing postmortem include?#

Google's SRE book defines a post-mortem as a written record of an incident, its impact, the actions taken to resolve it, the root causes, and the follow-up actions to prevent a recurrence. The customer version keeps the same skeleton and drops the internal detail.

Write it blameless. The SRE book's test is that the document names contributing causes without indicting a person or team, on the assumption that everyone acted in good faith with the information they had. Customers do not want to know who pushed the change. They want to know why the system allowed it.

Atlassian's incident handbook, as of October 2026, adds the part most emails skip: identify the changes that prevent the whole class of incident, then commit to specific changes by specific dates. That sentence is the difference between a post-mortem and an apology.

• Impact first: what customers experienced, from [INCIDENT DATE] for [DURATION], in their terms rather than yours.
• Cause in plain language: one or two sentences someone outside engineering can repeat.
• What you changed already, and what is still pending.
• A dated list: each change with an owner team and a [BY WHEN].
• A way to reach a person, and what to do if the customer was hit harder than you describe.

What belongs in the email and what stays internal?#

Publish the root cause. Customers can tell when a cause has been softened to 'a technical issue', and that phrase tends to generate more follow-up questions than the real answer would. Say what failed at the level a smart non-engineer can follow.

Keep out anything that identifies individuals, exposes exploitable detail, or names other customers. Google's own postmortem chapter notes its documents never include information that could identify an end user. Apply the same rule: no customer names, no internal hostnames, no names of the engineers on call.

Template 1: the short RCA summary#

Use this when the fix has shipped and the customer base is small enough that a full write-up would be overkill. Four short paragraphs is the target.

Template 2: the full public post-mortem announcement#

Use this for a major outage that customers discussed publicly. Post it on your status page or blog and send a short email that points to it. The longer version carries the timeline.

Template 3: the enterprise-specific version#

An enterprise customer has a contract, a procurement team and usually someone who will forward your email to their own leadership. Send this from a named person, not a no-reply address, and offer a call without making them ask.

Do not pre-empt a service credit conversation in the post-mortem itself. If your contract has one, handle it in a separate note so the root cause is not buried under billing language.

Template 4: the repeat-incident version#

This is the hard one, and it is covered at length in the next section. The short form: do not apologize a second time in the same words. Lead with the fact that this is the same root cause, name what the first fix missed, and attach a dated list.

Template 5: the note to customers who were not affected but asked#

Some customers hear about an incident on social media or from a colleague and ask whether they were hit. A silent reply feels evasive. A long one makes a small thing look big.

Template 6: the holding note when the cause is not confirmed#

If you do not know the root cause yet, say so and commit to a date. Guessing in writing and being wrong costs more trust than waiting.

Template 7: when a vendor or dependency caused it#

Customers hired you, not your cloud provider. Naming the vendor as the whole explanation sounds like deflection. Explain what failed upstream, then own what your design did with it.

Template 8: closing the loop once the fixes ship#

Most teams stop after the first post-mortem. Sending this one is cheap, and it is the only email in the set that proves you kept the dates you promised.

What is the hard version of this situation?#

The second incident from the same root cause is where the standard post-mortem breaks. A customer who read your first email already knows the shape of the apology, so a second one lands as noise. What they are checking now is whether the first set of promises meant anything.

Atlassian's handbook states the principle as 'never have the same incident twice': fix the class of incident, not the instance, and commit to specific changes by specific dates. A repeat incident means your first fix covered the instance. Say that plainly, because customers will already have worked it out.

So the brief for a repeat-incident email is different. Replace the apology with a dated remediation list. Name what the first fix missed. State which of the earlier commitments were finished, and be honest about any that were not. Then add a date for an outside check, such as an independent review of the remaining risk.

Should you publish the root cause of an outage?#

Yes, at a level of detail that helps the customer decide whether to trust you. A vague cause invites speculation, and speculation is usually worse than the truth. Hold back only what would help an attacker or identify a person.

If the cause is a security matter, a different email applies. See the related post on security incident disclosure, because the legal and disclosure considerations are not the same as for an availability incident.

What should you do if there is no reply?#

Silence after a post-mortem is normal. Most customers read it, decide you handled it, and move on. Do not chase a reply to a note that did not ask for one.

Follow up in two cases. First, enterprise accounts you offered a call to: send one short nudge a few working days later with two fresh time slots, then stop. Second, any customer who replied angry and then went quiet: a named person checking in once, without a template feel, does more than a second broadcast.

For everyone else, the follow-up is Template 8. It arrives when you have something to show, and that is the only follow-up that is a reason to open an email.

• One nudge to accounts you invited to a call. Then stop.
• A personal check-in to anyone who replied angry and went silent.
• No chasing broadcast recipients. Send Template 8 when the work is done.
• Log every reply, because next time it shows you which customers care about which failures.

Where AI Emaily fits in a post-incident week#

The templates above solve the writing problem. The practical problem is the week after an incident: forty replies from customers, each needing a different version of the same facts, from the same person who just spent two days on the incident itself.

We build AI Emaily, so weigh this accordingly. It drafts those replies in your voice from the Personal Context and client profiles you set up, so the enterprise reply sounds like you and the small-account reply sounds like you too. In approval mode nothing sends until you approve it, which matters for an email with root-cause claims in it. Undo and an audit log cover the rest.

It is not a status page, an incident tool or a bulk sender, and it is the wrong choice for broadcasting to your full customer list. Use your status page or email service for that. It fits the one-to-one replies that follow. The 7-day free trial and plan details are on aiemaily.com/pricing, and the homepage at aiemaily.com has the overview.