Maintenance has an awkward property: when it works, there is nothing to show. Nothing broke, nothing was exploited, the site stayed up. From the client's side that is indistinguishable from nobody doing anything.
This is the entire reason maintenance retainers get cancelled. Not dissatisfaction, but the slow accumulation of months in which the client saw an invoice and no evidence. A report is the artefact that fixes it, and the mechanism is simple: it replaces "I pay for maintenance and nothing breaks" with "my agency applied 47 updates, closed a vulnerability before it was exploited, and kept the site up 99.9 percent of the month".
What belongs in one
Updates applied. Plugins, themes, and core, with versions before and after. This is the bulk of the work and the easiest thing to understand. You do not need to explain what each update did.
Backup status. When the last successful backup ran, how often they run, and where they are stored. "Backed up daily to encrypted offsite storage" reassures people who could not define any of those terms, which is most clients.
Uptime and performance. Uptime for the period, typical response time, and any incidents. Report incidents even when they went well; an outage you detected and resolved in nine minutes is a strong argument for your retainer, and hiding it wastes the best evidence you have.
Security. Vulnerabilities found and patched, settings changed, suspicious activity blocked. For security-conscious clients this section alone justifies the engagement.
Manual work. Content changes, configuration, support requests handled. This is the part that varies per client and usually has to be written rather than generated, and it is also the part clients read most closely, because it is the part they remember asking for.
What to leave out
Detail that alarms rather than informs. "We patched a SQL injection vulnerability in the checkout plugin" and "we applied a critical security update" describe the same event. The first invites a panicked email asking whether card data was exposed. Give the second, and keep the specifics available if asked.
Anything you have not verified. Do not report a backup as successful because it was scheduled. A report is a claim, and one wrong claim discovered later costs more credibility than the entire report earns.
Vanity metrics. Number of files scanned, requests processed, queries cached. It reads as padding, and padding invites the question of whether the rest is padding too.
Raw tool output. A pasted list of thirty plugin slugs and version numbers is data, not a report. Summarise, and attach the detail if the client is the sort who wants it.
Automation requires the data to exist first
Assembling reports by hand does not survive contact with a portfolio. At fifteen minutes each across forty clients, that is a full day a month spent transcribing, and it is the first thing to slip when you are busy, which is precisely when clients most need reassurance.
The prerequisite is not a report generator. It is a record. If every update, backup, scan, and setting change is captured with a timestamp and an outcome as it happens, a report is a query over that record. If the information lives in your memory, in Slack, and in three people's notes, no tool can assemble it, because the data was never collected.
This is why reporting belongs in the operational system rather than beside it. WPMgr records every operation in a per-site audit log, and reports are generated from that log on a schedule you set: monthly or quarterly, delivered by email, PDF, or both, using a template configured once per client.
The reason to care about the log specifically is that it is also the answer to a dispute. When a client asks what you did in March, or whether a change was yours, the log is a record made at the time rather than a reconstruction made under pressure.
Branding, and what it actually signals
A white-label report carries your agency's name and identity, not your vendor's. Header, logo, colours, footer contact details, and a title under your own name.
The substantive reason is not vanity. A report branded with a third-party tool tells the client exactly which product you use and how much it costs, which reframes your retainer as a markup on a subscription they could buy themselves. That is not a conversation you want, and it is not even an accurate one, since what they are paying for is judgement, response, and accountability rather than software.
Keeping the tooling invisible keeps the conversation on the service. It is also simply true that the client's relationship is with you: when something breaks at midnight, they are not calling the vendor.
Structure it for someone who reads the first page only
Most clients read the summary and stop. That is not a failure of the report, it is the normal behaviour of a busy person, and the structure should assume it.
Put the conclusion first: a short block with uptime for the period, the number of updates applied, backup status, and whether anything needed attention. Someone who reads only that should come away with an accurate picture.
Then the detail, in sections they can skip. Then anything requiring a decision, clearly marked, at a place they will reach if they are the sort of reader who reaches it, and repeated in the delivery email if it genuinely needs action.
The mistake is opening with a table of every plugin update. It is the longest section, the least interesting, and it buries the two facts the client actually wanted.
Numbers need context to mean anything. "99.94 percent uptime" is meaningless to most people; "99.94 percent uptime, about 26 minutes unavailable across the month, during a host network incident on the 14th" is a sentence a client can evaluate. Where you can, show the direction of travel against previous periods, because a stable number stated monthly eventually reads as boilerplate.
The month something went wrong
The instinct when a month has gone badly is to soften the report. This is exactly backwards, and how the report gets its credibility.
If a site was down for two hours, say so: when it started, what caused it, when it was resolved, and what changed so it is less likely to recur. A client who reads an honest account of an incident you handled competently trusts every future report more. A client who later discovers an outage that was not mentioned stops trusting all of them, including the accurate ones.
The same applies to work that did not happen. If an update was deferred because it would have broken a checkout customisation, that is a legitimate engineering decision and worth stating. Silently omitting it means that when it surfaces later, it looks like negligence rather than judgement.
There is a practical benefit too. Documented incidents are the record you need when a client asks why they should keep paying for monitoring, and they are the evidence behind a recommendation to move a site to better hosting.
Cadence and delivery
Monthly suits most maintenance retainers, and it matches the billing cycle, which is the point. The report should arrive near the invoice, so the value is present in mind when the cost is.
Quarterly works for lighter engagements. Weekly is almost always too frequent: it dilutes each report and trains the client to ignore them.
Deliver by email, with the report attached or summarised in the body. A portal the client has to remember to visit will not be visited. If you use one, send an email when a report is ready, and put the two or three numbers that matter in the email itself so a client who never clicks still receives the message.
Use it as an account management surface
The best-run agencies treat the report as a conversation opener rather than a receipt.
A site running an outdated PHP version, a plugin whose developer has stopped maintaining it, a steady rise in traffic approaching a hosting limit, a Core Web Vitals score that has been drifting for three months: each is a legitimate observation from your monitoring and each is a natural lead-in to work the client actually needs.
That reframes the report from evidence you did the minimum to evidence you are paying attention. It is also the honest version of upselling, because the recommendation comes from data you were already collecting rather than from a quota.
The client who never opens them
Some clients will never read a report. That is not a reason to stop sending them, and it changes what the report is for.
Unread reports still do two jobs. They create the record you need the day someone questions six months of invoices, and they mean the value was communicated whether or not it was received, which is a materially different position to be in during a renewal conversation.
What is worth adjusting is the delivery. For a client who does not open attachments, put the three numbers in the email body so the message lands even if nothing is clicked. For one who never replies at all, a short call once a quarter walking through the last three reports will do more than twelve more emails.
Why this reduces churn
Churn on maintenance retainers is rarely a decision that something was done badly. It is a slow erosion of perceived value across months where nothing visible happened, ending in someone reviewing recurring costs and finding a line item they cannot justify.
A monthly report that documents real work, real incidents caught, and real uptime makes that line item defensible without anyone having to argue for it. The work was always happening. The report is what makes it countable.
For report configuration and white-label settings, see the white-label reports feature page. For how reporting fits into running a portfolio, see managing multiple WordPress sites and the for agencies solution guide.