---
title: How to Tell a Client Their Website Went Down — Email and Status Update Templates
description: Copy-and-paste website outage messages for first notice, investigation, ongoing updates, mitigation, resolution, and the final incident report.
source: https://pingvera.com/blog/client-website-down-email-templates.html
---
# How to Tell a Client Their Website Went Down: Email and Status Update Templates

The first outage message does not need a root cause.

It needs four things:

1. acknowledgment;
2. known impact;
3. current action;
4. time of the next update.

Silence creates speculation. An overconfident explanation creates a second incident when it turns
 out to be wrong.

Use the templates below before the outage, not while everyone is improvising.

## Template 1: first notice

**Subject:** Investigating an issue with [website/service]

`Hi [Client name],

Our monitoring detected an issue affecting [website/service] at [time and timezone].

Known impact: [pages may be unavailable / forms may not deliver / checkout is failing].
We are investigating now.

We will send the next update by [time], even if the investigation is still in progress.

[Agency name]`
 Do not wait for a full diagnosis. Atlassian's incident communication guidance recommends
 acknowledging the issue, summarizing known impact, and promising the next update.

## Template 2: investigation update

**Subject:** Update: [website/service] incident

`Hi [Client name],

The issue is still under investigation.

Current status:
- [What is working]
- [What remains affected]
- [What the team is checking]

The root cause is currently [unknown / believed to be X but not yet confirmed].

Next update: [time and timezone].

[Agency name]`
 Saying "root cause unknown" is better than omitting it and letting the client assume you forgot to
 investigate.

## Template 3: mitigation applied

**Subject:** Update: service restored, monitoring in progress

`Hi [Client name],

We applied a mitigation at [time]. [Website/form/checkout] is currently working again.

We are monitoring recovery and have not yet closed the incident.

Known impact:
- Incident window: [start–current]
- Affected function: [function]
- Data or lead impact: [confirmed statement / still being assessed]

Next update: [time].

[Agency name]`
 Do not say "resolved" immediately after pressing deploy. Confirm from the visitor perspective.

## Template 4: resolution

**Subject:** Resolved: [website/service] incident

`Hi [Client name],

The incident affecting [function] was resolved at [time and timezone].

Impact:
- Start: [time]
- End: [time]
- Affected function: [function]
- Confirmed business impact: [facts only]

Resolution:
[One or two plain-language sentences.]

We are completing the incident review and will send [a final report / corrective actions] by [date].

[Agency name]`

 Template 5: no confirmed client impact
 Use this carefully. "No impact" must be supported.

`Our monitoring detected a brief regional failure from [region/provider]. Checks from other regions remained successful, and no customer-facing outage or form-delivery failure was confirmed.

The event is closed as a provider-specific monitoring incident. We will continue watching for recurrence.`
 This is better than sending an alarming "site down" message and quietly retracting it later.

## Status page versions

Status updates should be shorter than email.

### Investigating

> We are investigating failures affecting [service]. Some users may be unable to
>  [impact]. Next update by [time].

### Identified

> We identified the issue affecting [service] and are applying a mitigation. [Impact]
>  remains affected. Next update by [time].

### Monitoring

> Service has recovered after mitigation. We are monitoring stability before closing the
>  incident. Next update by [time].

### Resolved

> The incident was resolved at [time]. [Service] is operating normally. A summary will
>  follow for affected stakeholders.

## What not to write

Avoid:

- "Everything is broken."
- "It is definitely the hosting provider" before confirmation.
- "No data was lost" before verification.
- "Should be fixed now."
- raw stack traces;
- internal blame;
- promises with no next update.

Replace "should be fixed" with evidence:

> Successful form submissions were confirmed from Frankfurt and Virginia at 11:03 UTC.
>  Monitoring will continue for 30 minutes.

## Assign a communication owner

During a meaningful incident, the person diagnosing the system should not also be interrupted
 every three minutes to rewrite client messages.

Assign:

- incident owner;
- technical lead;
- communication owner.

For a small agency, one person may hold two roles. The roles should still be explicit.

Atlassian recommends a central source of truth, regular updates, and communication tailored to the
 audience. External clients generally need short impact and recovery information, not every
 technical branch of the investigation.

## Choose one primary channel

Use one canonical location:

- status page;
- incident ticket shared with the client;
- email thread;
- client portal.

Other channels should point to it. This prevents email, Slack, and phone updates from contradicting
 one another.

## After the incident

Send a final report containing:

- executive summary;
- impact;
- detection;
- timeline;
- contributing factors;
- resolution;
- corrective actions with owners and deadlines.

Then add the incident and completed corrective work to the monthly client report. The outage was
 bad; a clear response can still strengthen trust.

## Frequently asked questions

**How often should clients receive updates?**

Set the interval based on severity. For an active customer-impacting incident, Atlassian
 recommends not going more than an hour without an external update and always stating when the
 next update will arrive.

**Should an agency call the client?**

For severe business, security, or data impact, call the agreed emergency contact and follow
 with a written record.

**What if the client noticed first?**

Acknowledge it directly, open the incident, and improve detection afterward. Do not argue
 about timestamps while impact continues.

## Sources

- [Atlassian incident communication best practices](https://www.atlassian.com/incident-management/incident-communication)
- [Atlassian incident response handbook](https://www.atlassian.com/incident-management/handbook/incident-response)
- [Prometheus alerting practices](https://prometheus.io/docs/practices/alerting/)