Monitoring has an awkward property: when it works, nothing happens. The site stays up, the certificate renews on time, the vulnerable plugin gets patched before anyone exploits it. From inside the agency, that is a good month. From the client's side of the invoice, it looks identical to a month in which nobody did anything. Sooner or later the gap surfaces as the question every agency owner recognises: what did we actually pay for this month?
The work is real. The evidence just never gets collected. Client reporting is the fix, and it is less about persuasion than about bookkeeping: recording the invisible work somewhere the client will actually see it.
Why monitoring is invisible work
Retainers mostly buy prevention, and prevention that succeeds leaves no trace. The client experiences outcomes, and the outcome of good monitoring is the absence of incidents, which feels exactly like the absence of effort.
A hypothetical but familiar example: an agency's monitoring flags a client's SSL certificate three weeks before expiry, because the auto-renewal had silently broken. Someone fixes the renewal in twenty minutes. The client experiences nothing, which was the entire point, and also the entire problem when the retainer comes up for review. Multiply that by uptime incidents caught at 2am, expiring domains renewed early and broken links fixed before Google noticed, and a busy month of prevention compresses into a client-visible record of zero.
The alternative to reporting is worse than silence. It is the client discovering the value only when something fails, which is the one moment the retainer looks bad regardless of the years it worked.
What a good monthly report contains
A useful report is short, numeric and specific to that client's sites. Six sections cover it.
- Uptime, with downtime minutes. Not just "99.98%": also "9 downtime minutes on the 14th, detected within a minute, resolved in 9". Numbers and times, not adjectives.
- Issues caught and fixed. The certificate renewed early, the plugin updated after a vulnerability disclosure, the form that stopped submitting. This is the section that answers the retainer question directly.
- Visual and content changes. What changed on the site this month, expected or not. It reminds the client the site is being watched, not just hosted.
- Scan results. Security, malware, blacklist and accessibility checks, including the clean ones. A clean scan is still a result; unreported, it is indistinguishable from an unrun one.
- Performance. The PageSpeed trend, and whether Core Web Vitals moved. One chart is enough.
- Upcoming renewals. Domains and certificates due in the next 60 to 90 days. This turns the next quiet save into visible, planned work instead of another invisible one.
Keep the whole thing readable in two minutes. The detail can live in a dashboard for the client who wants it. The report exists for the client who does not.
Send on a schedule, not on request
A dashboard the client can log into sounds like transparency. In practice almost no client logs in, so "the data is all there if you want it" becomes "the client never sees the data". Dashboard-on-request also fails at the worst possible moment: the client who finally asks for evidence is usually the one already doubting the retainer, and assembling six months of proof under that deadline is not a strong position.
A report that arrives on the first of every month solves both problems. It reaches the client whether or not anyone asked. It builds the record before it is needed. And the rhythm itself carries information: someone is watching, every month, on schedule. Send-on-schedule is the difference between reporting as evidence and reporting as damage control.
White-labelling, and why it matters
The report should carry the agency's branding, not a monitoring vendor's. The client hired the agency; the tools are the agency's business. A third-party logo on the monthly report quietly reframes the relationship as "we forward you a tool's emails", and invites the obvious next thought about buying the tool directly. Under the agency's own name, the same report reads as what it actually is: the agency's monitoring service, delivered.
White-labelling matters most for exactly this document, because the monthly report is often the only artefact of the retainer a client ever sees. If one thing carries your brand, it should be this one.
How TLDTrack handles it
TLDTrack builds these reports from the monitoring data it already collects, so there is nothing to assemble by hand. You build a named report once and it sends itself: which clients receive it, which of their sites it covers, which of the 16 sections appear and in what order, up to 2,000 characters of your own intro, and whether it goes out monthly on a day from 1 to 28 or weekly on a weekday, at an hour you pick in UTC. A preview pane renders the real email with a chosen client's real data while you edit, and sends that preview to any address you type so you can read it before they do. Each report reaches the client's portal contacts plus up to 10 extra recipients, and a Send now button covers the mid-month meeting where the client asks how things are going. The builder is on Pro and Agency plans, and Agency plans white-label the email with your portal branding. The mechanics are on the client report builder page, setup details are in the client reports guide, the wider agency workflow is covered on the agencies page, and if you are still deciding what to monitor per client in the first place, start with our complete guide to monitoring client websites.
