The site was down for 50 minutes on a Tuesday afternoon, you fixed it, and now the client wants "a report". What you send next decides whether this becomes the story of the time your agency screwed up, or the time your agency showed it had the situation in hand. Most agencies send a three-line email; the ones that keep clients through a bad month send a one-page post-mortem.
When a client incident earns a written post-mortem
Not every hiccup needs a document. A 90-second blip during a plugin update that nobody noticed is a line in the monthly report, not a post-mortem. Google's SRE book lists the triggers its teams use: user-visible downtime beyond a threshold, any data loss, a manual intervention such as a rollback, resolution taking longer than a set time, or a monitoring failure where a human found the problem before the alerts did (Postmortem Culture: Learning from Failure). Translate that to a care plan and you get a short, written rule you can put in the contract:
- The client site was unavailable or visibly broken for more than 15 minutes.
- Anything was restored from backup, or an update was rolled back on a live site.
- A client, not your monitoring, reported the problem first.
- Forms, checkout or logins silently failed for any length of time.
- Someone got into the site who should not have.
Write the thresholds down before the first incident. Deciding "is this bad enough?" while the client is on the phone is how post-mortems don't get written.
The six parts, in order
A client post-mortem is one page. It is not the internal one your team keeps. It has six parts, and the order matters because clients read the top and skim the rest.
1. One-paragraph summary. What broke, when, for how long, and that it is fixed. Three sentences. "Between 14:02 and 14:52 UTC on 21 October, example.com returned a server error on every page. The cause was a failed update to the WooCommerce plugin. The site was restored at 14:52 from the restore point taken before the update, and orders placed after that time have been processed normally."
2. Impact, stated plainly. Downtime in minutes, what visitors saw, what was lost and what was not. If 12 orders failed at checkout, say 12 orders. If you don't know, say what you checked and what you couldn't. A client who learns the real number from their own analytics three days later stops believing your reports.
3. Timeline. Detection, first response, diagnosis, fix, confirmation, in local time with the client's timezone. Pull it from your activity log rather than memory. The timeline is where "we noticed within two minutes" becomes a verifiable claim instead of a reassurance.
4. Cause. The chain, not the villain. "The 9.4.1 update changed a database table; the site's PHP 8.1 build of the payment extension could not read it and threw a fatal error on every page." If the chain includes the client ("the password shared with the former contractor was still active"), state it as a fact in the chain, without a sermon.
5. What we did. The fix, and the checks you ran afterwards: screenshots compared, checkout tested, forms submitted, search console checked for errors.
6. What changes. Two to four concrete actions with a date and an owner, some yours and, where true, some the client's.
Blameless outward, honest inward
The SRE chapter's rule is that a post-mortem focuses on contributing causes "without indicting any individual or team for bad or inappropriate behavior". That is written for engineers reading each other's reports, but it is the right rule for clients too, in both directions.
Don't blame your own junior for running the update at 2pm; the process let a 2pm update happen on a store. Don't blame the host for a 40-minute support queue; the plan had no fallback for it. And don't blame the client in the document, even when they caused it. A sentence like "the staff login shared in 2024 was never revoked" states the cause; "your team gave out passwords" starts a fight. The action list is where the client's part lands: "Client: confirm the list of people who should have admin access by 4 November."
The honest-inward half is the one agencies skip. If your monitoring didn't catch it, the post-mortem says so, because the client will ask anyway and "our checks run every 60 seconds" means nothing if the alert went to an inbox nobody read.
What to leave out
Server logs, stack traces and plugin version diffs belong in the internal write-up, with a line in the client version saying they exist and are available on request. Hourly billing for the fix does not belong in the same document; send the invoice separately, or better, say explicitly that the incident was covered by the plan if it was. Speculation about causes you haven't confirmed stays out entirely; "we are still confirming why the cron job stopped" is fine, a guess dressed as a finding is not. And leave out the phrase "unforeseen circumstances", which every client reads as "we weren't looking".
Timing and the arithmetic of credibility
Send the summary within the hour, the full page within two business days. The two-day limit forces you to write while the activity log is fresh, and tells the client this is routine for you rather than a special effort.
The maths behind why this is worth 45 minutes of your time: a $150-a-month care plan is $1,800 a year, so a client lost to one badly handled incident costs you $1,800 of recurring revenue plus whatever it took to win them. A post-mortem takes roughly 45 minutes if the timeline comes from a log and 2 to 3 hours if it comes from memory and Slack scrollback. At $100 an hour that is $75 against $1,800. Even if only one incident in ten would have cost you the client, the expected saving per post-mortem is $180, more than twice its cost. The actual number of incidents you'll handle on 60 sites in a year is in the dozens, so the habit pays for itself the first quarter.
| Part | Length | Source |
|---|---|---|
| Summary | 3 sentences | Written last, from the rest |
| Impact | 3–5 lines | Uptime log, orders/forms data, analytics |
| Timeline | 5–8 entries | Activity log, alert timestamps, ticket thread |
| Cause | 1 paragraph | Error log, update record, your diagnosis |
| What we did | 3–5 lines | Restore record, your post-fix checks |
| What changes | 2–4 actions, dated | Agreed with the client |
A template you can paste
Keep one file called postmortem-template.md in your agency repo and copy it per incident. Headings: Summary. Impact. Timeline (table of time, event). Cause. What we did. What changes (table of action, owner, date). Footer: "Incident covered under your care plan: yes/no. Internal technical notes available on request." Fill the timeline first, because once you have the timeline the summary and the cause mostly write themselves. If an incident started with a client email rather than an alert, say so in the timeline; that honesty is the thing clients remember, and it is also the finding that should change your monitoring. The companion piece on handling the first email, the "my site is broken" triage system, covers the hour before the post-mortem exists.
Where this leaves you
The post-mortem is the one document a client reads from start to finish, so it is the cheapest trust you will ever buy. Most of its contents, the timeline, the restore point used, the screenshot comparison after the fix, already exist if your tooling keeps an activity log you can show a client. WPClientHub records every update, restore point, rollback and uptime check per site with timestamps, so the timeline is a copy-and-paste rather than a reconstruction; it is free for 3 sites, paid plans from $19/month. Connect your sites and see what the log looks like after your next incident.