Most monthly backup reports are written to be sent, not read. A page of green ticks and a percentage near a hundred goes out on the first of the month, the client glances at it, and nobody learns anything. Then a restore fails in March and the client asks why every report since January said everything was fine.
A useful report answers the question the client actually has: are my backups working, and when they were not, what did you do about it? It can be short. It has to be honest.
Who reads it, and what they need
The person who opens the report is rarely technical. It might be a practice manager, a finance director or the owner of a small business. They do not need job logs. They need to know three things:
- Whether their data was protected this month, in numbers they can compare with last month.
- What went wrong, in plain words, and whether it was fixed.
- Whether anything is still wrong today.
Write for that reader. Leave the job IDs and repository names in the appendix, if there is one.
What to include
A success rate with a clear definition. Successful runs divided by all runs. Say what counts as successful, and do not count runs that completed with warnings. A warning usually means something was skipped: a locked file, an unreachable mailbox, a virtual machine that could not be snapshotted. Counting it as a success hides exactly the things the client should hear about.
What was received, broken down. OK, warning and failed reports, each as a number. The client can see that 4 failures out of 600 runs is a different month from 4 failures out of 30.
Missing reports, as their own number. This is the one most reports leave out. A success rate is calculated over the reports that arrived. A backup that never ran sends nothing, so it is not in the calculation at all, and the rate looks better the more the backups fail silently. Count the expected reports that did not arrive and show that figure next to the rate. A backup can fail by saying nothing explains how to know which reports were due.
Incidents and how long they took to fix. An incident is a stretch of trouble on one backup, from the first bad report to the first good one. List them, and give a typical time to recover. Use the median, not the average: one incident that took four days because a replacement disk was on order will drag an average far away from what usually happens, and the median stays honest about the typical case while the incident list shows the outlier.
What is open now. Anything still failing or missing on the day the report is produced. A report that only covers the past can be technically correct and still mislead.
A short per-backup table. One line per backup, with its own counts. This is where a weekly job that failed every week shows up, even when the overall rate looks fine.
Avoiding vanity percentages
A percentage is easy to make look good. A few habits keep it truthful:
- Do not pool everything into one number. An hourly database job produces over 700 reports a month; a weekly file server backup produces four. Pooled together, the file server can fail every single week and the overall rate barely moves. Show the per-backup lines alongside the total.
- Do not round up. 98.6% is 98.6%, not "99%".
- Do not quietly drop the bad days. If a backup was excluded from the month because "it was being migrated", say so in the report. If it was not protected, the client needs to know.
- Compare against a target the client agreed to, not against an industry figure. If the agreement says 99.5%, report against 99.5%.
None of this makes the report look worse than the service. It makes the good months believable.
Explaining misses honestly
The incidents are the part a client reads most closely. For each one, a sentence or two covers it:
- What happened, in plain words. "The nightly backup of the accounts server failed for three nights because the backup disk was full."
- What it meant for their data. Were restore points lost? Was an older copy still available?
- What changed so it does not happen again.
Resist the urge to soften it. "A temporary issue affected backup operations" tells the client you would rather not say. "The disk filled up; we added capacity and an alert at 80% full" tells them you found and fixed the cause.
This is far easier if the explanation is written when the problem is fixed, not reconstructed at the end of the month. A one-line note on each resolved incident becomes the incident table almost by itself.
Cadence
Monthly suits most clients: often enough to stay current, rare enough to be read. Quarterly fits a client who prefers a review meeting, as long as something reaches them in between when an incident is serious. Internally, a team usually wants a weekly look, which is a different report for a different reader.
Whatever you choose, keep it regular. Same day each month, same layout, same definitions. A client who sees the same report every month notices when a number moves. A report that arrives late, or only in good months, tells them something too.
Settle the month boundaries as well. A backup that runs at 23:30 on the last day belongs to one month or the next depending on whose clock you use. Pick one timezone and use it every time.
Links or attachments
There are two ways to deliver a report, and they behave differently.
An attached file is simple and works offline. But it lives forever in mailboxes, gets forwarded to people you never meant to see client names and server names, and cannot be corrected once sent. If a number was wrong, the wrong number stays in circulation.
A read-only link keeps the report in one place. It can expire after a set time, so last year's report does not stay reachable indefinitely, and it can be withdrawn if it was sent to the wrong person. You can also see whether it was opened, which tells you whether the report is being read at all. The cost is that the recipient has to click, and some will want a file for their own records or an auditor.
A reasonable default: send a link that expires, and offer a data file to the clients who ask for one.
Client reports and share links in BackupSentinel
The Reports page builds a monthly client report for one client and one month, in the workspace timezone. It shows the Success rate (OK reports divided by all reports, so warnings do not count as successes), Reports received split into OK, warning and failed, Failed reports, Missing reports, Incidents with their Median recovery over the incidents resolved in that month, and Open now, followed by a table per backup and a table of incidents. The success rate is shown against the client's SLA target when one is set: Standard 99.0%, Gold 99.5%, Platinum 99.9% or a custom figure. Any member of the workspace, viewers included, can build a report; saving it to Saved reports needs an owner, admin or member.
From a report you can Download CSV, or share a read-only link. A link covers that client and that month, works for 7, 30 or 90 days, needs no sign-in, is kept out of search engines and can be revoked at any time. The page says "Read-only · link valid until …", and the report lists how many times each link has been opened. The figures are worked out when the link is opened, so a link to the current month shows the month so far.
There are no PDF reports: the report lives on the page, the link and the CSV. The monthly client report is not sent on a schedule either; Scheduled reports send a CSV health snapshot by email daily, weekly, monthly or quarterly instead. How far back a report can go depends on the plan's retention.
More detail is in Reports and on the Reports feature page.