What to put in a monthly website care report

The awkward truth about looking after a website is that a good month looks identical to doing nothing. No outage, no hack, no broken checkout. Whoever is paying sees an invoice and no events, and somebody in a finance meeting asks what it is for.

A monthly report is the answer to that question. Whether you send it to a client or file it internally, it is worth treating as a deliverable in its own right rather than an export you forward because the tool produced one.

Write it for the person who signs the invoice

That person is usually not technical and usually did not commission the site. They cannot evaluate “99.98% uptime” or “12 plugins updated”. Those are inputs, and they read as a list of things that were done rather than a list of things that were got. The report has to answer three questions in their language:

1. Did the things my customers do actually work this month?
2. Did anything break, and what happened about it?
3. Is there anything I need to decide?

What belongs in it

The flows that bring in the money, named specifically

Not “the site was monitored” but “the booking form was checked 1,440 times this month and worked every time”. Name the flow the way the business names it: the booking form, the contact form, the checkout. Not the way the tool names it.

Anything that broke, with what it meant

Every incident should carry three things: what happened in plain language, what a visitor would have experienced, and what was done about it. “Between 09:14 and 09:41 the booking calendar did not open for visitors. It was caused by an update to the scheduling plugin and was rolled back.” That is a paragraph anyone can forward to their own boss.

Evidence, not assertion

A screenshot of the failure is worth more than any description of it, and it is the difference between a report that says you were paying attention and a report that demonstrates it.

Anything that needs a decision

A certificate expiring, a plugin that is no longer maintained, a page getting slower each month. Put it in front of them while it is cheap. This section is also where next year’s work comes from.

What to leave out

• Raw metrics with no interpretation. A response-time chart with no sentence saying whether that is good is decoration.
• Vanity uptime. “99.99%” means nothing to someone who does not know what the missing 0.01% was, and it invites the wrong argument if there was an outage.
• Task lists. Plugin updates are how the work got done, not what was bought.
• Anything you cannot substantiate. A report is a document you may have to stand behind later.

Make it look like yours

A report is one of the few documents about the website that actually gets read. If it arrives carrying a monitoring vendor’s branding, whatever goodwill it earns goes to the vendor. Your logo, your colours, your footer. And it should be forwardable exactly as it is, because it will be forwarded.

Send it on the same day, every month

Predictability is most of the point. A report that arrives on the first Tuesday every month becomes part of how the work is experienced. One that arrives only when there is news teaches people that no news means nothing is happening.

JourneyPing produces this report from what it actually checked: flows named the way the business names them, failures written twice, evidence attached, in your branding, as a link or a PDF. If you build yours another way, the structure above still holds.