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
• Atlassian incident response handbook
• Prometheus alerting practices

---

Originally published at pingvera.com.