5 Downtime Notification Email Templates for Web Agencies

Silence During an Outage Is the Real Problem

When a client site goes down, most agencies instinctively focus on fixing the problem before saying anything. That instinct is understandable — but it tends to make things worse.

Clients often notice the outage before you do, or receive complaints from their own customers. Every minute of silence reads as "they have no idea what is happening." By the time you send a recovery notice, the client is already frustrated and looking for someone to blame.

The first notification does not need to explain what went wrong. Its only job is to say: "We know, and we are on it." A brief, confident message sent within 15 minutes does more for client trust than a detailed report sent an hour later.

This article covers what to include in a first-notification email and provides ready-to-use templates for the most common outage scenarios. For the full post-incident report that follows, see the incident report template for web agencies.

Five Elements Every First Notification Must Include

Keep the message short. If you have time to write a long email, you have time to spend on the fix instead. These five elements are the minimum.

1. Subject Line That Shows Urgency Without Panic

The subject line is the first thing the client sees. Make the status clear immediately.

[Site Down — Responding Now] Client Name | Outage Detected

Avoid words like "emergency" or "critical failure" — they create alarm without adding information. "Responding now" shows that your team is already acting.

2. Detection Timestamp

Telling the client exactly when you detected the problem shows that your monitoring is working and that you moved quickly. If you use automated monitoring, you can pull this timestamp directly from the API.

# Retrieve detection timestamp from Miterl incident history
curl -s "https://miterl.com/api/v1/incidents?monitor_id=YOUR_MONITOR_ID" \
  -H "Authorization: Bearer YOUR_API_KEY" | \
  jq '.data[0] | {started_at: .started_at, cause: .cause}'

3. Current Status in One Sentence

State what your team is doing right now. Even "investigating the cause" is better than nothing — it tells the client something is happening.

4. Time of Next Update

Name a specific time for your next message. "You will hear from us by 3:30 PM" is far more reassuring than "we will keep you posted." It also prevents the client from sending follow-up emails every ten minutes.

5. Direct Contact Information

Include a phone number or direct email for the on-call person. Clients who know they can reach someone immediately feel much calmer, even if they never use the number.

Copy-Paste Templates

Template A: Cause Unknown (Most Common)

Use this when the site is down and you have not yet identified why.

Subject: [Site Down — Responding Now] [Client Name] | Outage Detected

Dear [Client Name],

At [Time], our monitoring system detected that [site URL] was
inaccessible. We are currently investigating the cause and working
to restore the site as quickly as possible.

We will send you an update by [Time + 30 minutes] or sooner if
we have news. If the site is not fully recovered by [Time + 1 hour],
we will send another update at that time.

For urgent matters, please contact [Name] directly at [Phone/Email].

[Your name]
[Your agency]

Template B: Cause Identified

Use this when you know what went wrong and are actively fixing it.

Subject: [Site Down — Fix in Progress] [Client Name] | Outage Update

Dear [Client Name],

At [Time], our monitoring system detected that [site URL] was down.
We have identified the cause and are working on the fix now.

Current status:
  - Detected at: [Time]
  - Cause: [Plain-language explanation, e.g., "The web server ran
    out of available memory and stopped processing new requests."]
  - Action: [What your team is doing right now]

We expect the site to be restored by approximately [estimated time].
We will confirm recovery as soon as it is complete.

For urgent matters, please contact [Name] at [Phone/Email].

[Your name]
[Your agency]

Template C: Outage Discovered After Hours

Use this when monitoring detected a downtime event overnight and the site has already recovered.

Subject: [Overnight Outage — Resolved] [Client Name] | Incident Summary

Dear [Client Name],

I want to let you know that our monitoring system recorded a
downtime event on [Client Name]'s site last night.

What we know so far:
  - Outage detected: [Time]
  - Recovery confirmed: [Time]
  - Duration: approximately [X minutes]
  - Current status: fully operational

We are reviewing the logs to determine the cause and will send a
full incident report — including root cause and prevention steps —
by [time today].

If you have any questions in the meantime, please reach out to
[Name] at [Phone/Email].

[Your name]
[Your agency]

Template D: Recovery Confirmed

The recovery notification is the message agencies most often skip, because once the site is back the pressure is off. Skipping it is a mistake: the client is still refreshing the page wondering whether the problem is really over. Send this the moment monitoring confirms recovery — not after you finish writing the incident report.

Subject: [Recovered] [Client Name] | Site Is Back Online

Dear [Client Name],

[Site URL] is back online as of [Time]. We have confirmed normal
operation through our monitoring system.

  - Outage began: [Time]
  - Recovery confirmed: [Time]
  - Total duration: [X minutes]
  - Cause: [One-sentence plain-language explanation]

We are now reviewing the incident in detail and will send a full
report — including root cause and the steps we are taking to
prevent a recurrence — by [date/time, within 24 hours].

Thank you for your patience during the outage.

[Your name]
[Your agency]

Confirm the exact recovery timestamp from your monitoring history rather than from when you personally noticed the site loading again:

# Confirm recovery timestamp and total duration for the latest incident
curl -s "https://miterl.com/api/v1/incidents?monitor_id=YOUR_MONITOR_ID" \
  -H "Authorization: Bearer YOUR_API_KEY" | \
  jq '.data[0] | {started_at, resolved_at, duration_seconds}'

Template E: Prolonged Outage With SLA Impact

Use this when the outage has run long enough to threaten your uptime commitment. The instinct here is to go quiet until you have good news — which is exactly when clients start calling. Acknowledging the SLA implication before the client raises it keeps the conversation on your terms.

Subject: [Ongoing Outage — Hour 2] [Client Name] | Status and Next Steps

Dear [Client Name],

[Site URL] has now been unavailable for approximately [X hours].
I want to give you a clear picture of where we stand.

  - Current status: [What is confirmed working / not working]
  - Cause: [What you know, and explicitly what you do not yet know]
  - Work in progress: [Specific action underway right now]
  - Escalation: [Who has been brought in — hosting provider,
    senior engineer, vendor support ticket number]

Regarding our service agreement: this outage is expected to
consume approximately [X]% of this month's uptime allowance. We
will address the SLA implications formally in the incident report.

Next update: [specific time, no more than 60 minutes out].

[Name] remains available at [Phone/Email] throughout.

[Your name]
[Your agency]

Stating what you do not yet know is what makes this message credible. A status update that implies full control during a two-hour outage reads as evasive; naming the open questions reads as honest. For how the uptime allowance is calculated in the first place, see the uptime percentage calculator guide, and for which outages can legitimately be excluded, see maintenance window best practices.

Sending the Same Update to Slack or Chatwork

Many agencies run a shared channel with the client instead of — or alongside — email. The channel version is not the email pasted in; it needs to be short enough to read on a phone lock screen.

🔴 [Client Name] site down — detected 14:12
Investigating now. Next update by 14:45.
Contact: [Name] / [Phone]

🟢 [Client Name] site recovered — 14:38 (26 min outage)
Cause: web server memory exhaustion. Full report by tomorrow 12:00.

Keep email as the system of record even when you post to a channel: the email thread is what you will reference months later during a contract review. Sending these channel messages automatically on detection is covered in sending uptime alerts to Slack and Chatwork.

Timing Guidelines

Hitting the 15-minute target during business hours is realistic only with automated monitoring. When a human notices the problem, the detection delay alone often exceeds 15 minutes. Miterl checks sites every minute and sends an alert the moment a site goes down, so you receive the notification before your client does.

Common Mistakes in First Notifications

From First Notification to Final Report

The first notification starts a communication chain. Here is the full sequence:

First notification (within 15 min of detection)
  ↓
Progress updates (every 30–60 min if outage continues)
  ↓
Recovery notification (immediately on recovery)
  ↓
Incident report with root cause and prevention (within 24 hours)

The incident report at the end of this chain is where you provide the full account: timeline, root cause, response log, and prevention measures. Use the incident report template to build that document. For the complete incident response workflow that ties all of these steps together, see the incident response guide.

How Miterl Speeds Up First Notifications

The bottleneck in first notifications is almost always detection speed. An agency that finds out about downtime from the client has already lost the trust advantage.

Miterl monitors sites at one-minute intervals and sends alerts via email, Slack, or Chatwork the moment a site becomes unreachable. When you receive that alert, you can paste the template above and send the first notification in under five minutes.

To retrieve accurate detection timestamps for your notifications:

# List recent incidents for all monitors
curl -s "https://miterl.com/api/v1/incidents" \
  -H "Authorization: Bearer YOUR_API_KEY" | \
  jq '.data[] | {monitor: .monitor_id, started: .started_at, resolved: .resolved_at, duration_sec: .duration_seconds}'

For how to price monitoring into your maintenance contracts, see how to price monitoring into maintenance contracts. The business case for adding monitoring to agency services is covered in the monitoring ROI guide for agencies.

Try Miterl free

Frequently Asked Questions

How soon should I email a client after their site goes down?

Within 15 minutes of detection during business hours. That target is only realistic with automated monitoring — if a human has to notice the outage first, the detection delay alone usually eats the window. For overnight outages that have already recovered, send by the first hour of the next business day.

Should I notify the client before I know the cause?

Yes. The first notification's job is to say "we know and we are on it," not to explain the failure. Template A above is written specifically for this case. Waiting until you can explain the cause means the client spends that entire time assuming you have not noticed.

Do I need to send a recovery email for a short outage the client never noticed?

Send it. A two-minute outage that you report yourself builds confidence in your monitoring; the same outage discovered later in a report the client did not expect looks like something you tried to hide. Keep it to the Template D format and it costs you a minute.

Should I apologize in the first notification?

Apologize, but not first. Lead with what you are doing right now, then apologize briefly. An email that opens with an apology and never states the current action reads as passive and gives the client nothing to hold onto — that is the most common mistake in the table above.

What do I write when the outage is the hosting provider's fault?

Name the provider and the ticket number, but do not use it to deflect responsibility. The client contracted with you, not with the host. Template E's "Escalation" line exists for exactly this: it shows you have engaged the vendor while keeping ownership of the outcome.

How many notifications is too many during one outage?

Every 30 to 60 minutes while the outage continues, and always at the specific time you promised in the previous message. Missing a promised update time damages trust more than the outage itself; sending early with "no change yet, next update at X" is always better than silence.

Summary

The first notification after an outage is not about having answers. It is about showing your client that you are already working on it. A brief, confident message within 15 minutes prevents the frustration that builds during silence.

• Send before you have all the facts — speed matters more than completeness here
• Always include: detection time, current status, next update time, and a direct contact
• Use Template A when the cause is unknown, Template B when you have identified it, Template C for overnight events, Template D on recovery, and Template E when the outage threatens your SLA
• Never skip the recovery notification — it is the message that closes the loop and the one agencies most often drop
• Follow up with a full incident report within 24 hours of recovery

For monitoring configuration and alert setup, see the documentation. For agency-specific use cases, the use cases page has practical examples. Frequently asked questions about getting started are answered in the FAQ.

With your notification templates ready, the next design decision is the escalation chain: which alerts go directly to the on-call engineer, which ones copy a manager, and when does the client get a direct call rather than an email. Structuring this clearly in advance means you are not making judgment calls under pressure during an actual outage. "Monitoring Alert Escalation Guide: Designing Your On-Call Notification Flow" walks through severity classification, escalation tiers, and quiet hours policies for agency teams.