Website Incident Report Template for Clients

July 12, 2026 · 4 min read

An incident report should reduce uncertainty.

It should not defend the agency, bury the client in logs, or invent a root cause before the investigation is complete. It should establish what happened, who was affected, how the issue was handled, and what will prevent a repeat.

Below is a client-ready template you can copy and adapt.

When to write an incident report

Write one when an incident:

• caused meaningful downtime;
• stopped forms, checkout, login, or another critical path;
• exposed visitors to a malicious redirect or unsafe content;
• involved possible data or security impact;
• repeated after a previous fix;
• requires client budget or a technical change;
• is likely to appear in a renewal or stakeholder conversation.

Small incidents can use a shorter version. The discipline still matters.

Copy-and-paste template

# Website incident report

Incident: [Short factual title]
Client: [Client name]
Website or service: [URL/service]
Severity: [Critical / High / Normal]
Status: [Resolved / Monitoring / Open]
Incident window: [Start–end, timezone]

## Executive summary

[Two or three sentences: what failed, who was affected, how long impact lasted,
and current status.]

## Customer impact

- Affected function: [website / form / checkout / login / other]
- Affected users: [known scope or "not yet confirmed"]
- Business impact: [known impact; avoid unsupported estimates]
- Data/security impact: [confirmed / none observed / still under investigation]

## Detection

- Detected at: [timestamp]
- Detection source: [monitor / client / team / provider]
- Time to detect: [duration]

## Timeline

- [10:42] First confirmed failure
- [10:44] Monitoring opened incident
- [10:48] Responder acknowledged
- [11:01] Mitigation applied
- [11:03] Recovery confirmed from [regions/checks]
- [11:20] Monitoring period completed

## What happened

[Factual technical explanation appropriate for the client.]

## Contributing factors

- [Factor 1]
- [Factor 2]

## Resolution

[What restored service.]

## Corrective actions

| Action | Owner | Deadline | Status |
|---|---|---|---|
| [Action] | [Owner] | [Date] | [Open/Done] |

## Evidence

- Incident ID: [ID]
- Monitoring checks: [links]
- Change/deployment: [link]
- Relevant provider ticket: [link]

## Next update

[Date/time, or "This report is final."]

Write the executive summary last

The summary should include only verified facts:

From 10:42 to 11:03 UTC, the contact form accepted submissions but did not deliver them to the sales inbox. Monitoring detected the failure at 10:44. Delivery was restored by correcting the mail integration, and successful tests were confirmed from two regions. The number of affected leads is not yet known.

Notice what it does not do:

• blame a person;
• claim no leads were lost;
• use raw stack traces;
• describe every investigative dead end.

Build a factual timeline

Use monitoring timestamps, deployment history, chat records, and provider events. Keep these separate:

• first failure;
• first detection;
• acknowledgment;
• mitigation;
• restoration;
• confirmation.

"Resolved" should mean the user-facing function has recovered, not only that a configuration change was made.

Root cause versus contributing factors

Complex incidents rarely have one magical root cause.

Instead of:

A developer made a mistake.

Write:

A configuration change disabled the mail route. The deployment lacked a post-release form-delivery test, and the previous monitor checked only the HTTP response.

The second version identifies system improvements.

Atlassian recommends blameless postmortems focused on what happened and how to prevent recurrence, not who to punish.

Corrective actions must be testable

Weak:

Improve monitoring.

Useful:

Add a synthetic form-delivery check every five minutes, owned by Web Operations, due July 18.

Every action needs:

• an owner;
• a deadline;
• a completion test;
• a status.

Client language versus technical appendix

The client report should explain impact and response. Put these in an appendix:

• raw logs;
• stack traces;
• full request/response bodies;
• internal chat;
• security-sensitive details;
• personal data;
• unverified hypotheses.

Transparency does not require publishing secrets.

Frequently asked questions

Should every outage get a full postmortem?

Use a proportional process. Every incident should have a record; major, repeated, security-related, or business-critical incidents deserve a full report.

Should the agency apologize?

If the client was affected, acknowledge it directly. Do not make legal or data-impact claims before they are verified.

When should the report be sent?

Send operational updates during impact. Send the final report after facts are confirmed and corrective actions have owners.

Sources

• Atlassian incident response best practices
• Atlassian incident communication guidance
• Atlassian incident handbook

Read next: client outage email templates and your client's site went down.