2026-05-31

Downtime Notification Email Templates for Web Agencies

incident response client communication web agency templates

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]

Timing Guidelines

Situation Target
Outage detected during business hours Within 15 minutes of detection
Outage detected overnight, site recovered By the first hour of the next business day
Outage continues beyond 30 minutes Progress update every 30 to 60 minutes

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

Mistake Why It Backfires Fix
Waiting for the fix before notifying Client fills the silence with frustration Send before the fix, not after
Apologizing without stating current action Sounds passive; no confidence communicated Lead with what you are doing, then apologize
Omitting the next update time Client emails every 10 minutes for status Always name a specific next-contact time
Writing a long first message Takes too long; information is stale by send time Keep it to five sentences maximum

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

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
  • 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.