2026-05-26

Client Incident Report Template for Web Agencies

incident response client communication web agency templates

Why Agencies Dread Writing Incident Reports

When a client site goes down, the hardest part is often not fixing the problem — it is writing the report afterward. "How much detail is too much?" "Will being honest make things worse?" This hesitation leads to vague, delayed reports that do more damage than the outage itself.

An honest, structured post-incident report is the fastest way to restore client trust. Clients do not expect perfection — they expect transparency and a credible plan to prevent a repeat.

This guide covers the six elements every incident report needs and provides a ready-to-use template.

Six Elements Every Incident Report Must Cover

A strong incident report answers three questions for the client: What happened? Why did it happen? Will it happen again?

1. Timeline: Start, End, Duration

Give exact timestamps. If you use Miterl, this data is available directly from the API.

# Retrieve incident history for a monitor (filter by monitor_id)
curl -s "https://miterl.com/api/v1/incidents?monitor_id=1" \
  -H "Authorization: Bearer YOUR_API_KEY" | \
  jq '[.data[] | {cause: .cause, started_at: .started_at,
    resolved_at: .resolved_at, duration_sec: .duration_seconds}]'

Pull the exact start and recovery timestamps from the incident history and paste them into the report. No estimates.

2. Impact Scope

Be specific. "The site was down" is not enough. Write "The homepage and product listing pages were inaccessible. The checkout process on a separate subdomain was unaffected."

The more precise your scope statement, the more professional the report reads — and the clearer it is that you understand your own system.

3. Root Cause in Plain Language

Avoid jargon. A client who does not work in IT should be able to understand the cause. Compare these:

Weak: "There was a server error."
Strong: "The web server ran out of available memory and could not process new visitor requests."

If the root cause is still under investigation at the time of the first report, say so explicitly and give a timeframe for the update.

4. Chronological Response Log

List what your team did and when. Each entry should be a concrete action, not a vague status update.

"14:37 — Automated monitoring detected downtime and alerted on-call engineer"
"14:39 — First notification sent to client"
"14:52 — Root cause identified as memory exhaustion"
"15:04 — Server process restarted; site confirmed operational"
"15:15 — Full functionality verified and client notified of recovery"

5. Prevention Measures with Deadlines

This is the most important section. Avoid generic commitments like "we will be more careful." Write specific actions with dates.

"By June 5: Configure a memory utilization alert to trigger at 80% capacity"
"By June 10: Increase server memory allocation from 2 GB to 4 GB"
"Starting June: Include monthly server resource review in maintenance checklist"

6. Next Communication Date

Tell the client when they will hear from you again. Even a simple "we will confirm that prevention measures are in place by June 10" closes the loop and prevents follow-up emails.

Copy-Paste Template

Subject: [Incident Report] [Client Name] — Site Outage on [Date]

Dear [Client Name],

Thank you for your patience during the recent outage. We want to provide
a full account of what happened and the steps we are taking to prevent a
recurrence.

INCIDENT SUMMARY
----------------
Start time:    [Date] at [Time]
Recovery time: [Date] at [Time]
Duration:      Approximately [X hours / Y minutes]
Affected:      [Specific pages or services]

ROOT CAUSE
----------
[Plain-language explanation of what went wrong. One to three sentences.]

RESPONSE TIMELINE
-----------------
[Time] — Automated monitoring detected the outage and alerted our team
[Time] — First notification sent to you
[Time] — Root cause identified: [brief description]
[Time] — [Action taken, e.g., server restarted]
[Time] — Site confirmed operational; full functionality verified
[Time] — Recovery notification sent to you

PREVENTION MEASURES
-------------------
To reduce the risk of a similar incident, we are taking the following steps:

1. [Specific action] — target date: [date]
2. [Specific action] — target date: [date]
3. [Specific action] — ongoing from [date]

FOLLOW-UP
---------
We will confirm that all prevention measures are in place by [date].
If you have any questions before then, please do not hesitate to reach out.

[Your name]
[Your agency]

Making Report Writing Faster

Most of the data in this template — detection time, recovery time, and downtime duration — comes directly from your monitoring tool. Using the Miterl API, you can pull accurate timestamps and downtime figures without relying on memory or digging through logs.

For the broader incident response workflow that feeds into this report, see the incident response playbook. If you want to reduce client inquiries during an outage before the report is even written, a status page for clients handles that automatically.

Summary

A good incident report is honest, specific, and forward-looking. Use the template in this article as your starting point, customize the prevention section to your actual situation, and send it within 24 hours of recovery.

Give exact timestamps, not approximate ranges
Explain root cause in language any client can understand
Every prevention measure needs a concrete action and a deadline
Close the loop by stating when the client will hear from you next

Review the documentation for Miterl's monitoring and alerting features. For agency-specific workflows, the use cases page has practical examples. Common setup questions are answered in the FAQ.