Monitoring backups without a dashboard or an agent: the email-forwarding approach

Before you install anything, count what you already have. Every backup tool in your estate is already sending you a report by email, every night, for every job. That’s a monitoring feed. It’s just landing in a mailbox nobody reads.

Most of the MSP people I talk to reach for the opposite: a new dashboard, an agent on every endpoint, a connector per vendor. That’s a project. Forwarding email is an afternoon.

Why forwarding beats installing something #

• Nothing to deploy. No agent on a client server, no change window, no software approval.
• No credentials to hand over. You’re not giving a third party API access to the backup system itself. You’re sending it a report that’s already been generated.
• It works with the tools that don’t have an API. The 9-year-old NAS, the rsync script somebody wrote before you took over the account, the appliance nobody wants to touch. If it can send an email, it’s covered.
• It survives vendor changes. A forwarding rule doesn’t care that Veeam shipped a new version last week.

The tradeoff is real: you only see what the tool chose to put in the report. If a job never runs, no email gets sent, and silence looks exactly like success. More on that below — it’s the pitfall that bites hardest.

Setting it up #

1. Inventory what actually sends mail. Per client, list every backup job and where its report goes today. This is the step people skip, and it’s the one that finds the two jobs whose notifications were pointed at an admin who left in 2023.

2. Pick one destination address. A dedicated mailbox or alias, not somebody’s personal inbox. Whether you split it per client depends on how you bill and escalate — decide it now, because changing it later means touching every job again.

3. Forward at the source, not with a mailbox rule. Add the address to the tool’s notification recipients directly. A rule in your own inbox is one more thing that breaks silently, and it usually matches on subject — which puts you right back in keyword territory. That trap is the whole subject of why backup monitoring fails silently .

4. Send a real report through the pipe. Not a test email you typed yourself — an actual job report, so you find out now whether the formatting survives.

5. Test the failure case too. Almost everyone tests a success and stops there. Force a job to fail: rename the target folder, pull a credential, point it at a full volume. The failure email is the one that has to make it through intact.

The pitfalls that break it #

HTML-only reports. Some tools send an HTML body with no plain-text alternative. Anything downstream that only reads the plain-text part sees an empty message. Forward one and look at what actually arrives.

“Forward as attachment” vs inline. Forwarding as an attachment wraps the original in a .eml file. Some setups handle it, some see an empty body with a file stuck to it. Inline forwarding is the safer default — but it can also mangle HTML layout. Test whichever you pick.

The result lives in the attachment. A fair number of tools send a subject like “Backup report attached” and put the actual outcome in a .log, .csv, or .html file. The email body tells you nothing. If your process only reads bodies, those jobs are invisible.

Digest emails. One message bundling twenty jobs, nineteen fine and one failed. Anything that classifies the message as a whole will call it a success. Where you can, configure per-job notifications instead of the nightly summary.

Forwarded mail gets flagged. Auto-forwarding can break SPF and DMARC alignment, and forwarded reports land in spam or get rejected outright. Check the destination’s spam folder a few days in, not just on day one.

Silence. The big one. A disabled job, a dead scheduler, a mail relay that quietly stopped working — none of them generate an email. Reacting to reports as they arrive can’t catch this, because there’s nothing to react to. Whatever you put in place has to know which reports it expects and flag the ones that never showed up. Done by hand, that’s a list of expected jobs per client checked against what actually came in each morning — the step homemade setups almost always skip.

What to do with the reports once they land #

Forwarding solves delivery. It doesn’t solve reading. You still need something that opens each report, works out whether it means success, warning, or failure, and only pings you for the ones that matter — because an alert on every report is one you’ll be filtering into a folder within a fortnight.

You can do that by hand while the volume is small. Past a dozen clients, the arithmetic stops working.

That’s the gap BackupMonitor.cloud fills: you forward the report emails to a dedicated address, each one gets classified within minutes, and an alert (email or Pushover) only goes out when something looks off. No agent, no dashboard to check, no per-tool rules to maintain.

It also covers the silence problem — it tracks the reports it expects and alerts you when one stops arriving, so a job that quietly died doesn’t just disappear from your morning.

If your reports are already arriving somewhere nobody reads them, the 7-day trial on BackupMonitor.cloud doesn’t require a credit card.