The backup failed on Tuesday. The disk died on Friday. Between those two events sat a red line in a console nobody opened — and that gap, not the software, is what actually hurt.
Every mature backup system fails sometimes: a PC was off, a repository hiccupped, a laptop went travelling. Failure is normal. Not noticing is the disaster. Site Manager gives you two safety nets — notifications that come to you, and a dashboard that tells the truth when you look — and this guide sets up both, then builds the five minute morning habit that ties them together.
Configure the console's notification settings so backup results are emailed: at minimum, failures and warnings, not just the daily success summary nobody reads. Send them to a shared IT mailbox or a distribution list, never to one person's inbox — the week that person is on leave is statistically the week something fails. Include the summary email too, but file it separately; the alert mails are the ones that should interrupt a morning. Test the settings by forcing a harmless failure — back up a machine you have deliberately disconnected — and confirm the mail actually arrives.
The console keeps per-computer history, so "is this new?" is always answerable. A failure with a three week history is not tonight's problem — it is an unprotected machine that has been waiting for you to notice.
Dashboards fail socially, not technically: nobody's job includes opening them. Make it somebody's job — yours, at a fixed moment, with coffee. Open the console, sort by status, and answer three questions: who failed, who warned, who has been silent too long? Anything red gets a ticket or a fix that day, and a backup run by hand so the gap is one night, not two. Five minutes daily is the entire cost of never being surprised by a dead PC with a three week backup gap.
Alert fatigue kills monitoring faster than any bug. One failed night on one PC is routine; the signals worth escalating are repetition and spread: the same machine failing three nights running, several machines failing together (that smells like the repository, the network or the server — a platform problem, not a PC problem), and repository space falling faster than your retention maths predicted. When several machines fail together, stop fixing PCs and go look at the shared parts first.
Server install, agent push, backup definitions and schedules — the whole Macrium Site Manager deployment, live and step by step.
▶️ Watch Full VideoYou will stop reading them within a fortnight, and then you will start ignoring the folder the failures land in too. Send successes into a daily summary if you want the record, and let failures and warnings be the mails that demand eyes. Silence should mean success — that only works if failures are guaranteed to break the silence.
Read its log before deciding. Intermittent failures often trace to the machine being off at schedule time, a flaky network drop, or a nearly full local disk slowing the snapshot. A pattern with an explanation is maintenance; a pattern without one is next month's restore problem arriving early.
Yes — the platform can export backup, computer and licence information, including scheduled automatic exports of audit and log data as files you can archive or feed into other reporting tools. Set the export up once and the 'prove we back up' question becomes a file you already have, instead of a scramble.