A monthly uptime report is not a technical document. It is the receipt for a service the client cannot see. When everything works, they see nothing, and a client who sees nothing eventually asks why they are paying. The report answers that question before it is asked.
This is what belongs in it, in the order the client reads it.
1. The verdict, in one sentence
Start with the answer: “Your site was available 99.98% of the time in October. Two short interruptions, both resolved within minutes.” If the month was bad, say so just as plainly. Do not make the client scroll to find out.
Avoid the temptation to open with a chart. A chart makes the reader do the work of deciding whether the month was good.
2. Availability as a percentage and as minutes
Percentages hide the thing clients care about. 99.9% sounds perfect and still allows about 43 minutes of downtime in a 30-day month. Show both: the percentage and the total minutes the site was unavailable. If you promise a target in your care plan, show it next to the result.
3. Incidents, one line each
List each incident with the date, the length, and one sentence on what happened and what you did. Keep the language of the person who reads it, not of the person who fixed it:
- “12 Oct, 7 minutes: the hosting provider restarted the server. Back online without action from us.”
- “27 Oct, 21 minutes: a plugin update broke the checkout page. Rolled back and fixed the next morning.”
If there were no incidents, write that there were none.
4. Response time, but only as a trend
Average response time is useful when it moves. “Pages answered in about 450 ms, in line with September” is a reassuring sentence. A table of daily averages is noise. Mention response time when it changed noticeably, and say what you think it means.
5. Certificates and domain
One line each: when the SSL certificate expires and when the domain expires. These are the two things that break a site on a fixed date, and clients are always grateful to learn they are being watched. Monitoring them is cheap and the sentence in the report is worth a lot.
6. What you did
If you updated plugins, restored a backup or fixed a slow query, list it. Monitoring tells the client the site is fine; this section tells them somebody earned that result.
What to leave out
- Technical detail nobody asked for. Status codes, request IDs and stack traces belong in your own notes.
- Per-check noise. Hundreds of individual checks are not a report.
- Blame. If the host caused an outage, say it was the host and what you changed to reduce the risk. Do not write a complaint.
- Numbers without a promise. If you never agreed on an uptime target, do not invent one in the report.
Make it automatic
A report you write by hand each month gets skipped in the busy month, which is exactly when the client needs it. Tenium builds a monthly PDF per client with your logo and colours and sends it on the first of the month, so the client gets the same report every month whether or not you remembered. On the Pro plan you get one branded report; on Agency each client workspace gets its own. The details are on the client reports page.
If you are still deciding how to package monitoring for clients, selling monitoring as a care plan covers the pricing side.
Frequently asked questions
How long should a client uptime report be?
One page. A client reads the top third and the verdict. Put the answer first, the details after it, and keep anything technical for the people who ask.
Should I send the report every month even when nothing happened?
Yes. A quiet month is the point of the service, and the report is the proof. A report that arrives only after an outage teaches the client to associate it with bad news.
Related
Monitor your first site free
30 monitors free, checks from 2 regions, no card. SSL and domain expiry from $7 a month.