The morning backup check is a ritual at many MSPs. It is essential, and it almost always drifts: twenty minutes at first, an hour six months later when the client base has doubled. Here is a method to keep it short without letting anything slip.

The principle: only look at what needs action

An efficient daily check is not about reading every report. It is about answering three questions:

  1. Which jobs failed?
  2. Which jobs sent no report when they should have?
  3. Which reports are ambiguous and deserve a human read?

Everything else, the successes that arrived on time, does not need to be read. It needs to be counted.

Step 1: the list of what you expect

Before you can be fast, you need an inventory: for each client, the list of backup jobs and how often they run. File server every night, Microsoft 365 every 12 hours, offsite copy on Sundays. Without that inventory, you cannot know that a report is missing.

Step 2: deal with missing reports first

Missing reports come first because they take the longest to diagnose and are the most dangerous. A failure tells you what went wrong; an absence tells you nothing. Note them, open a ticket, and check the console of the software concerned.

Step 3: failures and warnings

For each failure, the question is not “what does the error say?” but “is this the first time?”. A one-off failure after a network outage often clears itself the next night. Three failures in a row on the same job need action today.

Warnings are the classic trap: eventually nobody reads them. Sort them once and for all: the acceptable ones (a machine deliberately powered off) and the ones that never are (skipped files on a production server).

Step 4: ambiguous reports

Some reports don’t clearly say whether they are a success: unusual format, forwarded report, truncated text. Those are the ones to read. With a little practice they become rare, as long as you use direct notifications rather than forwards.

The mistakes that waste time

  • Reading successes one by one. They should be counted, not read.
  • Receiving everything in a single mailbox. Clients get mixed up and you lose track of what you expect.
  • Not recording incidents anywhere. The next day, you no longer know whether yesterday’s failure was already known.

With Soluax

The Soluax overview is built on this method: a “To handle” band gathers the tasks that failed or sent no report, then the reports to check and the open tickets. The rest fits on one line: “41 tasks monitored, 96% on time this month”. Each task also shows its month record, one mark per day, so you can see at a glance since when it has been slipping.

To get started, test your own reports in the free analyzer.