Outage emails customers actually read: three templates and the clocks between them

During an outage your customers do not experience your incident process — they experience your silence. The status page is a dashboard; the email is the apology that lands in the inbox of the person whose checkout just failed twice. The failure mode is predictable: fifteen minutes of quiet while everyone works the problem, then one email with no next-update time, then nothing until it's fixed. Each of those silences converts directly into tickets, refund demands, and churn. The fix is not better writing under pressure — it is three templates written in advance, with clocks attached, so that mid-incident nobody is composing from scratch.

This page gives you the three templates: the acknowledgment (sent inside 15 minutes, and its only job is to end the silence), the update (every 30 minutes while down, same skeleton every time), and the resolution (sent once customers are transacting again, with the credit line and the post-mortem link). Plus the subject-line patterns, the never-write list, the single-writer rule, and the refund decision. The clocks come from the same discipline as the incident communication timeline: a promise of “next update at 14:30” is a commitment, not a vibe.

1. The acknowledgment email (inside 15 minutes)

The acknowledgment has one job: prove a human saw it. It is not an explanation — you do not have one yet. Five sentences, no more:

Subject line: “We're aware of the checkout issue — next update at 14:30”. The subject carries the next-update time too, because some customers read the subject and nothing else. Never speculate about cause in the acknowledgment — the first cause you name out loud becomes the official story, and if it's wrong you now have two incidents.

2. The update email (every 30 minutes while down)

The update uses the identical five-sentence skeleton. That is the point: the customer should be able to read email three by skipping to the parts that changed. Only sentence three (what we're doing) and the facts ever change. If nothing has changed, say so honestly and pair it with what you have ruled out: “Still working on restoring checkout. We've ruled out the payment provider and are focused on our own queue layer.” That is a good update. What is not acceptable: re-sending the acknowledgment verbatim, or missing the promised update time — one missed cadence and every future clock you set reads as noise.

If you restore service between updates, the next scheduled update still goes out — as the resolution. Never let a promised update time pass silently because “the alert already fired.” The alert reached the on-call; the email reaches the customer.

3. The resolution email (after customers are transacting again)

The resolution email is the one customers forward to their boss, so it does the heaviest lifting. Four paragraphs:

• What happened — one plain sentence, cause included now that you know it: “A config change at 14:02 made our checkout queue reject all payment requests.”
• When it broke and when it ended — clock times, from your incident timeline: “Impact ran 14:04–14:51; you may have seen declined payments in that window.” Telling customers the window lets them audit their own orders instead of contacting you to ask.
• What changes so it doesn't repeat — one or two concrete guards: “Pre-deploy checks now block that config class, and a queue-depth alert pages us before customers see it.” Link the post-mortem when it publishes — within 72 hours.
• The credit line — see section 6. If a credit applies, state it here, automatically applied, with the amount.

4. Subject-line patterns

5. What never goes in an outage email

• An ETA you cannot keep. “Fixed within the hour” is a promise clock, and missing it costs more than silence. Give next-update times, not fix times.
• “We apologize for any inconvenience.” The conditional apology reads as legal boilerplate. Apologize for the specific thing: “We're sorry — your checkout was down for 47 minutes and that's our failure.”
• Blaming a vendor by name. If the gateway was down, say “a payment provider outage” — naming them invites a joint-customer mess and reads as deflection.
• Jargon. “Elevated error rates on the async settlement path” means nothing to a shop owner who lost a sale. Translate to what the customer experienced.
• “Everything is fine.” Mid-incident optimism ages worst of all. State what is known, what is unknown, and when the next word comes.
• New commit/push activity as proof of work. Customers do not read deploy logs; they read clocks.

6. The credit and refund decision

Decide the rule before the outage, write it into the resolution template as a conditional, and never negotiate it incident by incident. If you publish an SLA, the credit is arithmetic — state the number and apply it automatically: “Per our SLA, this outage exceeds our monthly uptime commitment; a credit of $X has been applied to your account, no action needed.” If you have no SLA, a goodwill credit still beats the churn conversation: “We've added a $50 credit to next month's invoice — no action needed.” One sentence, automatic, no cap in the fine print you then have to defend. A month of credit costs less than one enterprise account re-evaluating a vendor that went silent.

7. The single-writer rule

One comms lead per incident writes every customer email; everyone else feeds facts into the incident channel and never hits send. All three emails go from one address (support@ or status@), because customers replying to a thread need one place to land. The comms lead does not debug — the moment they start troubleshooting, the next-update clock stops, and the silence vacuum opens. This role, its clocks, and the handoff at shift change are defined in the on-call escalation structure; the outage emails are simply where that structure meets the customer.

8. Worked example: the 47-minute gateway outage

A twelve-person e-commerce SaaS: payment gateway outage, checkout down 14:04–14:51 on a Tuesday. Comms ran on the templates: ack at 14:12 (8 minutes, promised next update at 14:42), updates at 14:42 and 15:12 (the second arrived after restore, converting to the resolution as promised), resolution at 15:20 with the window, two named guards, and the post-mortem link published 61 hours later. Total: four emails. Result: zero “what is happening?” tickets during the outage, three accounts that opened cancellation flows talked back from it in the following week, one automatic credit applied. The team's retrospective note: the subject-line clock times did the work — customers replied to the updates with order numbers instead of anger, which turned the thread into a queue of audit requests the resolution email then closed.

9. Metrics for the email sequence

• Time to first email — impact start to ack sent. Under 15 minutes is the band; over 30 means the comms lead role was not staffed, which is an on-call finding, not a writing finding.
• Cadence-kept % — promised next-update times that were met. 100%, or an explanation per miss.
• Resolution email lag — restore to resolution sent. Under 30 minutes; the post-mortem link may follow separately within 72 hours.

From the HIVE80lab kit

• The First 30 Minutes — free incident quick-start
• Ops Starter Kit Vol. 2 — advanced incident response & communications, including the outage comms pack — $27
• Ops Mega Bundle — all 5 kits in one download — $29
• Custom Incident Runbook — done-for-you, built from your estate, 48h — $249