Downtime Email Templates You Can Send to Customers

When your service goes down, the clock starts immediately. Every minute between when downtime starts and when your customers hear from you is a minute of eroding trust. The customers who find out through your proactive email are far more forgiving than those who discovered it themselves.

These templates cover every stage of a downtime incident — from the initial alert through resolution and follow-up. Adapt the wording to your product and voice, but use the structure and timing guidance as-is.

---

Before the Templates: The One Rule

Send the first email before users report the issue to you.

This requires monitoring that alerts you within minutes of downtime starting — not 20 minutes later when your support inbox fills up. Domain Monitor checks your service every minute from multiple locations and sends an immediate alert when something fails. Create a free account to set up monitoring before you need these templates.

If users are emailing you to report the outage, you've already failed the most important rule of incident communication.

---

Template 1: Initial Incident Notification

Send this within 15–30 minutes of an incident starting, once you've confirmed it's real and not a false positive. You don't need to know the cause — you just need to acknowledge it.

Subject: [Product Name] — We're investigating a service issue

Hi [Name],

We want to let you know that we're currently investigating an issue affecting [Product Name].

What we know: [Brief, honest description — e.g., "Some users are experiencing errors when logging in" or "Our API is returning elevated error rates."]

What we're doing: Our team is actively investigating. We'll share an update within [30 / 60] minutes.

You can follow the latest status at: [status page URL]

We're sorry for the disruption and will keep you updated.

[Your name] [Product Name] Team

What not to do: Don't speculate on causes. Don't make promises about resolution time unless you're confident. Don't use vague language like "we're aware some users may be experiencing issues" when the service is clearly down for everyone.

---

Template 2: Incident Update (During Ongoing Downtime)

Send this every 30–60 minutes if the incident is ongoing. Even if you have nothing new to report, the act of sending an update demonstrates that you're actively working on it.

Subject: Update: [Product Name] service issue — [time]

Hi [Name],

A quick update on the service issue we notified you about.

Current status: [Still investigating / We've identified the cause and are working on a fix / Service is partially restored.]

[If you've identified the cause:] We've determined the issue is caused by [brief, plain-English description — e.g., "a database configuration change during our deployment earlier today"].

Next update: We'll send another update by [specific time] or sooner if there's news.

Current status is available at: [status page URL]

Thank you for your patience.

[Your name] [Product Name] Team

---

Template 3: Service Restored

Send this promptly when the service is back up. Don't wait — customers are checking and want confirmation.

Subject: Resolved: [Product Name] is back online

Hi [Name],

[Product Name] is now fully operational. We resolved the service issue at [time] UTC.

Duration: The service was affected from approximately [start time] to [end time] UTC — a total of [X hours / X minutes].

What happened: [Brief explanation — e.g., "A database connection pool configuration change caused our application servers to run out of available connections under normal load."]

What we've done: [What fixed it — e.g., "We've reverted the configuration change and are reviewing our deployment process to prevent similar issues."]

We'll share a full post-incident review [within 48 hours / by [specific date]] for customers who want the complete technical picture.

We're genuinely sorry for the disruption this caused. If you have questions or experienced specific issues as a result, please reply directly to this email.

[Your name] [Product Name] Team

---

Template 4: Post-Incident Review (Following Up After Resolution)

For significant incidents — anything lasting more than 30 minutes or affecting business-critical workflows — send a detailed post-incident review 24–72 hours after resolution.

Subject: Post-Incident Review: [Product Name] outage on [date]

Hi [Name],

Following the service incident on [date], we've completed our post-incident review and want to share what we found.

Incident Summary On [date], [Product Name] experienced an outage affecting [description of scope] from [start time] to [end time] UTC — a total duration of [X hours Y minutes].

Timeline

• [time]: Issue began
• [time]: Our monitoring detected the problem and alerted the team
• [time]: Root cause identified
• [time]: Fix deployed
• [time]: Service fully restored

Root Cause [Plain-English explanation of what caused the incident. Be honest and specific. Don't use technical jargon unnecessarily, but don't be so vague that it sounds like you're hiding something.]

Contributing Factors [Optional: any factors that made the incident worse or harder to resolve — e.g., "The incident occurred outside of business hours, which delayed detection by approximately 20 minutes."]

What We've Fixed

• [Specific change 1]
• [Specific change 2]

What We're Doing to Prevent Recurrence

• [Action item 1 — with owner and target date if known]
• [Action item 2]

We take reliability seriously and we're not satisfied with this incident. The changes above are already in place or actively in progress.

If you have questions or feedback about how we handled this incident, please reply to this email directly. We read every response.

[Your name] [Product Name] Team

---

Template 5: Short Incident (Under 10 Minutes)

For very brief incidents — a few minutes of downtime that resolved quickly — a short, combined notification and resolution email is appropriate.

Subject: [Product Name] — Brief service disruption this morning

Hi [Name],

We wanted to let you know that [Product Name] experienced a brief service disruption [today / this morning / on date] from approximately [time] to [time] UTC — a total of [X minutes].

The issue was caused by [brief description] and has been fully resolved.

If you were affected and experienced any issues during this period, please let us know.

We apologise for the disruption.

[Your name] [Product Name] Team

---

Tone and Style Notes

Be direct. "We experienced degraded performance across some service components" when the site was completely down for 45 minutes isn't being careful — it's being evasive. Customers see through it and it damages trust more than a straightforward explanation would.

Own the problem. Avoid language that distances you from the issue: "the infrastructure experienced..." sounds like you're blaming your servers. "We had a failure in..." is better.

Avoid jargon. Your customers aren't interested in the specifics of your database connection pool. Explain what happened in terms of what they experienced and what you've done about it.

Use specific times. "Earlier today" is vague. "11:42 UTC" is specific. Specific times help customers correlate the incident with issues they experienced.

Include the status page. Every email should link to your status page. It's the authoritative source for current status and customers should know where to find it.

---

Also in This Series

• SLI vs SLO vs SLA: A Practical Guide for Small SaaS Teams
• Incident Severity Levels Explained for Startups and Small Teams
• Planned Maintenance Notice Templates for SaaS Status Pages
• Better Uptime vs UptimeRobot: Which Is Better for Small SaaS Teams?
• Free vs Paid Uptime Monitoring: When Should You Upgrade?

See how to communicate website downtime and how to write a post-incident report for more on incident communication. If the outage was caused by a hosting provider issue, see how to prove website downtime to your hosting provider — the monitoring logs that power your customer communication are the same evidence you'll need to make an SLA claim.