How to write a monthly website care report clients actually read

What the report is for

It has three jobs, in this order:

1. Show that the site was looked after. What was watched, what was found, what was done.
2. Give the client what they need to decide. Anything that needs their approval or money, with a reason and a date.
3. Keep a record. If something goes wrong next quarter, the last six reports are the history.

It is not a data dump. Clients read the first screen and skim the rest, so write for that.

The first screen: the summary

Open with four lines, in plain words:

• Status: “The site was available for 99.70 percent of the month: one incident of 130 minutes on the 9th.” (An example; use your own figure and give the method below.)
• What we did: “Updated 14 plugins, renewed the certificate, restored a backup as a test.”
• What needs a decision: “The domain renews in 41 days; the card on file expires before then.”
• What is next month: “Theme update on the 12th; checkout test before the sale.”

If the month was uneventful, say so: “Nothing needed fixing this month. We checked X, Y and Z.” An honest quiet month is a good report.

The sections

1. Availability

Give the number, the period and the method in the same place:

• the period (1 to 30 June, 43,200 minutes);
• the URL checked and the success condition (status 200 and the expected text);
• how often and from where;
• minutes of downtime and what caused each incident;
• how gaps in the measurement were counted. A period with no valid measurement is not “up”. Say how many minutes were unknown.

A bare “99.9 percent” without these invites a quarrel; with them it is evidence. See Uptime SLA maths for the formulas.

2. Incidents

For each incident, four sentences:

• when it started and ended;
• what visitors saw;
• the cause, if known, and what changed just before (a deploy, a DNS change, a certificate, a plugin);
• what was done and what prevents a repeat.

If an incident was a false alarm, say that too: it shows the monitoring is being tuned.

3. What was watched, and what changed

A short table helps:

If something changed, say what and who changed it. A DNS record that someone else edited is worth reporting even when nothing broke.

4. Maintenance performed

List updates (core, plugins, themes), backups taken and restore tests, security scans, speed or accessibility fixes, content edits. Name the version where it matters. This is the section that answers “what am I paying for?”, so do not skip it in a quiet month.

5. Risks and recommendations

Things that will cost money or time soon: an end-of-life PHP version, a plugin that is no longer maintained, a certificate that must move to a different provider, a domain about to expire. For each: what, why now, cost, deadline and what happens if nothing is done.

6. Next month

Planned work and any dates the client must know.

Style rules

• Plain words. “The site was unavailable” beats “a 503 was observed on the origin”.
• Numbers with context. “7 incidents” means little; “7 incidents, 6 of them under two minutes” means something.
• No blame, no drama. State cause and fix.
• Same structure every month. Clients learn where to look.
• Short. One page is ideal; two is the limit for most sites.
• Don’t pad. An empty section can say “no changes”.
• Never invent. Don’t fill gaps with a reassuring number. If you did not measure it, say so.

Delivery

• Send it on the same day each month, to the person who pays and the person who cares.
• Send the PDF and a two-line email that repeats the summary.
• Offer a call when something needs a decision, not as a default.
• Keep the reports in the client’s folder so renewals have evidence.

A template to copy

Website care report: [Client], [Month Year]

Summary
- Availability: [x] percent ([n] minutes down of [N]); method below.
- Incidents: [n]. Longest: [duration] on [date].
- Done: [one line].
- Needs your decision: [item, date] or "nothing".

Availability
- Period, URL and success condition:
- Interval and locations:
- Minutes unknown (no valid measurement):

Incidents
- [date, time]: what visitors saw; cause; fix; prevention.

What we watched
- Certificate / Domain / DNS / Redirects / Search visibility:

Maintenance
- Updates, backups, tests:

Risks and recommendations
- [item; why now; cost; deadline]

Next month
- [planned work, dates]

Automating the report without making it cheap

Data collection should be automatic: the uptime figure, incident list, certificate dates and DNS changes come straight from stored checks. The judgement (what the incident meant, what to recommend) is the agency’s value and should be written by a person. A report that is entirely machine-generated reads like one, and clients stop opening it.

Questions

Sources

Read on 2 November 2026. Standards and vendor pages change; confirm the current text before you rely on it.

• Google Search Central, Block Search indexing with noindex (what to report on indexability) (developers.google.com)