You pay somebody every month to look after your website. At the end of the month an email arrives saying “maintenance completed”. You have no way of knowing whether anything happened at all.
This is the most common weak point in a maintenance arrangement, and it is entirely fixable. A monthly website maintenance report is the only evidence you get that the work was done, so it is worth knowing what a real one contains.
Why the report matters more than the plan
Maintenance is invisible when it goes well. Nothing breaks, nothing changes, and there is nothing to see. That is exactly the problem: a provider doing careful work every month and a provider doing nothing at all produce the same visible result for a surprisingly long time. The difference only shows up on the day something goes wrong.
The report is what separates them in the meantime. It is not paperwork — it is the thing you are actually buying alongside the work.
What a useful monthly report contains
Six things. None of them are hard to produce if the work genuinely happened.
- What was updated, by name and version. Not “plugins updated” but which plugins, from which version to which. This is the difference between a report and a receipt.
- When the backup was taken, and whether a restore was tested. The date matters. So does the answer to “has anyone ever restored one of these”.
- What the security scan found. Including the months it found nothing, said plainly. A report that only appears when there is bad news is not a monitoring service.
- Uptime for the month, with any incidents. If the site went down for eleven minutes on a Tuesday, that belongs in the report even though nobody noticed.
- Any content or fix requests you made, and what happened to them. Closed, pending, or quoted separately.
- Anything that needs a decision from you. A plugin that has been abandoned by its developer, a PHP version the host is about to retire, a licence expiring. This is the section that earns the fee.
The lines that should worry you
Some report wording is designed to fill space rather than tell you anything.
“Website optimised.” Optimised how, and measured against what? If no before-and-after number is given, nothing measurable happened.
“Security check passed.” Which check, run by what? A green tick with no tool named is a decoration.
“All systems normal” every single month, forever. Real sites have small events. A year of identical reports usually means the report is a template, not a record.
No mention of anything needing your attention, ever. Websites accumulate decisions. If none are ever surfaced, either they are being made without you or they are not being noticed.
What to do with the report when it arrives
Read the first and last sections and ignore the middle. The first tells you the routine work happened. The last tells you what is coming. The middle is detail you only need when something goes wrong — and when it does, that detail is exactly what makes the problem quick to trace.
There is no standard maintenance report template, and you do not need one — what matters is that the same six things appear every month so you can compare one month against the next. Keep them. Twelve months of reports is a maintenance history, and it is the single most useful thing to hand a new provider if you ever change, or to check against when a problem appears and somebody asks when the site was last touched.
What the report is worth on the day something breaks
This is the part that is hard to appreciate until it happens. The site stops working on a Thursday. The first question anybody sensible asks is what changed recently, and without a record the honest answer is that nobody knows.
With twelve months of reports, that question takes a minute. You can see that four plugins were updated on the 3rd, that the security scan flagged nothing, that uptime was clean until Thursday. That narrows the search from the whole site to one afternoon.
Diagnosis is mostly elimination, and a maintenance history eliminates most of it for free. The report is not admin overhead — it is the thing that makes the next problem cheap to solve.
If you do the maintenance yourself, write the report anyway
This sounds like busywork for a one-person business and it is the opposite. If you are the one applying updates, you are also the one who will be trying to remember, eight weeks later, whether you touched the checkout plugin.
A note in a spreadsheet is enough. Date, what you updated, anything that looked odd, whether the backup ran. Four columns. It takes two minutes after work you were doing anyway, and it turns a vague memory into a record.
It also tells you something over time. Six months of notes will show you which plugin causes trouble repeatedly, which is a decision you cannot make without evidence.
Ask for one before you sign
Any provider can show you a sample report from an anonymised site. If the answer is that reports are not really a thing they do, that is useful to know before rather than after.
Our own monthly website care includes a written report every month covering exactly these six sections, and our note on what belongs in a website maintenance contract covers the other terms worth agreeing before you start.