What to send a client every month

A monthly report exists to answer one question the client is too polite to ask directly: was my site fine, and if not, what did you do about it?

Everything that does not answer that is decoration, and decoration is what makes reports go unread. What follows fits on one page, takes ten minutes to produce, and two to read.

The template, section by section

Monitoring report: dupont-joinery (shop)
Period: September 2026

Availability: 99.4%
Incidents: 2, for 41 minutes in total

  12/09, 2:20pm to 2:52pm (32 min)
  500 error after the payment plugin update.
  Plugin rolled back to the previous version, vendor notified.

  27/09, 3:10am to 3:19am (9 min)
  Host restart, unannounced maintenance.
  No action on our side, no orders lost.

What we did this month
  Certificate renewal had been failing since March without saying so.
  Fixed on 04/09, and now monitored with a 30-day alert.

Next month
  Checking the catalogue links after the redesign planned for the 15th.

Five blocks, no charts, and the client knows everything they needed to know. The long version of each block follows.

The four things worth including

1. Availability, as a number. "99.4% over the month" is a sentence anyone can carry into a meeting. It also makes the following months comparable, which is where the value builds: one number in isolation says nothing, twelve in a row tell a story.

2. What went wrong, and for how long. Each incident: when it started, how long it lasted, what caused it. Two lines each. Resist the urge to soften: a client who learns about an outage from you trusts you more, not less. The one thing that genuinely damages a relationship is an outage the client heard about from a customer before hearing about it from you.

3. What you did about it. This is the section people skip, and it is the one that justifies the invoice. "Certificate renewal was failing since March; fixed and now monitored" is worth more than every graph on the page.

4. What you are watching next month. One or two items. It shows the work is continuous rather than reactive, and it gives the client something to agree with. It is also the only section that costs you nothing to write and buys you the right to invoice next month without explaining yourself.

Turning a number into a sentence

This is the exercise that separates a report that gets read from one that gets filed. The client is not buying measurements, they are buying peace of mind, and a measurement does not translate itself.

The rule fits on one line: no figure without the sentence that says whether it is good or bad. A percentage left on its own produces a phone call, never confidence. Writing that sentence is the entire skill, and it takes about fifteen seconds per figure once you have decided to do it at all.

And if the client asks what those forty-one minutes cost, the answer exists and can be worked out: what an hour of downtime really costs is a figure you had better have to hand before being asked.

What to leave out

Raw graphs with no sentence. A response-time chart nobody explains produces a phone call, not confidence.

Metrics that only mean something to you. Number of checks run, requests per day, probe success rate. The client is not buying checks.

Everything that did not change. A report that repeats last month's page with new dates trains people to stop opening it.

Untranslated technical vocabulary. "502 on the backend" becomes "the site showed an error for eleven minutes". The exact code belongs in your notes, not in the report.

The three mistakes that make a report useless

The report that reassures too much. Rounding 99.4% up to "all fine" removes the document's one purpose, which is being believed. On the day a serious incident happens, the client rereads the earlier reports looking for what should have been in them. If they find nothing, it is not the incident they will remember.

The report that complains. The opposite, rarer and equally costly: detailing every network hiccup and every thirty-second restart makes the site look fragile. A nine-minute incident at three in the morning is mentioned in one line, without drama.

The report that compares to nothing. A month on its own says nothing. Two figures side by side, this month and last, turn a measurement into a trend, and the trend is what the client remembers.

What the report does for you

It is written for the client, and it does three things on your side first.

It forces you to look. An estate that is monitored but whose incidents nobody rereads once a month is an estate where the same failures repeat without anyone noticing.

It makes invisible work visible. The months when nothing happens are exactly the months when people wonder what the retainer is for. The report is the only trace of what you prevented.

It prepares the budget conversation. A client with twelve reports in mind does not have the same discussion as a client who only remembers the last outage.

The rule about silence

Send it when nothing happened.

This feels like sending an empty page, and it is the single most valuable habit in the whole exercise. If you only report when there is a problem, every arrival of your email is bad news, and the months of quiet work, the ones you are actually being paid for, become invisible.

A one-line month is a fine month: "No incident. 100% availability. Certificate renewed on the 12th, valid until October."

How often, and to whom

Monthly suits almost everyone. Quarterly is too long for anyone to remember the incidents; weekly turns the report into noise, and it ends up read by nobody.

Send it to a named person, not a generic address, and on the same day each month. A report that arrives on the 3rd, then the 19th, then the 8th looks like a report produced when someone remembers. The date matters more than the content here: a predictable report gets opened, an irregular one gets archived unread, whatever is in it.

The report is also not the channel for emergencies: an outage in progress is reported immediately and by other means. What triggers a notification is a separate question, and the report is precisely where everything that did not deserve to wake someone up belongs.

Where it comes from

The report should be a by-product of the routine, not a project. If producing it takes an afternoon, it will be late, then quarterly, then abandoned.

That means the underlying record has to already exist: the availability figures, the incidents with their durations, what was done. Which is one more reason the naming and organisation matter more than the tool: a report is only as easy to write as your records are to read.

It is also the most concrete criterion for choosing between a home-made script and an outside service. A script tells you a site went down; it does not give you last month's availability, because it kept nothing. The honest comparison is here, and that row is the one that usually decides.

If you also track backlinks for that client, they belong in the same report: a lost link is a dated, verifiable fact, and it explains a dip nobody would otherwise have been able to attribute to anything. What link monitoring records fits in three more lines.

Finally, the part of the report that gains the most value over time is the third: what you did. It gets filled in during the incident, not at the end of the month, and the first fifteen minutes are exactly when you write down what you will need.