Proxmox Emails You After Every Backup — Here's the One-Line Fix

I still remember the small thrill of the first one. Backup successful. An email from my own cluster, sent at three in the morning while I slept — my little lab working the night shift without me. I felt like a real systems administrator for about a week.

Then the week ended and the emails didn’t. Every backup, every night, every node: another polite green checkmark in my inbox. I stopped reading them somewhere around day ten. I started swiping them away in bulk somewhere around day twenty. And that’s the actual danger — not the clutter, but the reflex it trains. The one email in that stack that will ever matter is the red one, and by the time it arrives, you’ve taught yourself to delete the whole pile unread.

Here’s my embarrassing proof. When I finally dug into this, I discovered my cluster had been faithfully mailing an address I’d stopped checking ages ago — a drawer full of green checkmarks nobody ever opened, every single one of them a routine success notice. Which means that if one of them had ever been red, it would have vanished just as quietly.

The good news: Proxmox isn’t being needy. The flood is one default doing exactly what it’s told, the sorting you need is already built in, and the fix is genuinely one command — reversible, cluster-wide, twenty seconds. Everything below is from my four-node Proxmox VE 9.2 cluster; the mechanism is the notification system that arrived in the 8.x era, so a current 8.x box behaves the same way.

Why Proxmox mails you every single time

It isn’t a bug, and it isn’t your backup job’s settings. Since the 8.x series, Proxmox VE has had a proper notification system, and it thinks in three pieces: events, matchers, and targets.

Every time something noteworthy happens — a backup finishes, a backup dies, replication trips over itself — Proxmox emits a notification event, and stamps it with a severity on the way out. Matchers are the routing layer: as the docs put it, “Notification Matchers route a notification event to one or more notification targets.” A matcher can carry rules that filter which events it grabs. And targets are the destinations — for a stock install, that’s an email target pointed at the address you gave the root account during installation.

Now the crucial sentence, straight from the official documentation: “A matcher without any matching rules is always true; the configured targets will always be notified.”

That’s the entire mystery. A fresh cluster ships with exactly one builtin matcher — on my box it’s literally named default-matcher — and it has no rules. No rules means it matches everything: every severity, every event type, every node. Everything flows to the builtin mail-to-root target, which mails the root account. Your 3am success notice isn’t spam; it’s a wide-open net doing its job.

And if you’ve been hunting through your backup job’s own settings looking for the off switch, here’s why you came back empty-handed: the old per-job email fields (mailto and mailnotification) are deprecated in favor of exactly this matcher system. The default job setting, notification-mode: auto, means “an email will be sent if mailto is set, and the notification system will be used if not” — so a job where you never configured an address rides the notification system, and the matcher owns delivery. The knob you’re looking for moved. It’s just one level up.

Want to see your own routing before touching anything? Ask the cluster:

pvesh get /cluster/notifications/matchers

On a stock box you’ll see a single entry. On mine it was named default-matcher, origin builtin, no match rules, pointed at mail-to-root — the wide-open net from the diagram above.

The sorting is already done — you’re just not using it

Here’s the part I found genuinely elegant once I stopped being annoyed. Proxmox already grades every event. The documentation is plain about it: “The following severities are in use: info, notice, warning, error, unknown.”

Better still, the docs publish an events table stamping each event type with its severity, and the two rows that matter for our problem couldn’t be clearer:

Read that twice, because it’s the whole fix: a successful backup and a failed backup are different severities. Routine hums along at info and notice; real problems arrive as warning and error. The grading is done, every event, out of the box. The stock matcher simply ignores the grades — no rules, remember — and ships it all.

So we’re not going to build anything. We’re going to hand the existing matcher one rule: only match the grades I’d get out of bed for.

The fix: one command, two flags

Run this on any node — the /cluster/ in the path means it’s cluster-wide configuration, so once is enough (one small perk of having built a cluster in the first place):

pvesh set /cluster/notifications/matchers/default-matcher \
--match-severity warning \
--match-severity error \
--comment "Email real problems only; routine info/notice stays quiet"

What this does, piece by piece: it edits the builtin matcher in place (no new plumbing, no new target), and gives it its first-ever match rule — a severity filter. From that moment, warning and error events match and get mailed exactly as before, immediately. info and notice events match nothing, and an event no matcher matches simply isn’t delivered anywhere. Your nightly backup successful — stamped info, per the table above — goes quiet. A backup failed — stamped error — still wakes you up.

That’s the trade, and it’s the right one: you lose the mail you never read, and keep the mail you can’t afford to miss. The --comment is optional but kind — it’s a note-to-future-you stored right on the matcher (you’ll see it again in the pvesh get output below), explaining why this matcher isn’t stock.

Verify it — and aim it somewhere you actually read

Trust, but pvesh get:

pvesh get /cluster/notifications/matchers/default-matcher

Two things to confirm in the output. First, match-severity lists both values as separate entries — warning and error — not one smushed warning,error string. Second, origin now reads modified-builtin instead of builtin: Proxmox’s own bookkeeping that you’ve customized a stock part. That origin field is your safety net, and we’ll use it in a moment.

Then the step my own story makes non-negotiable: make sure the mail lands somewhere you look. The mail-to-root target sends to the root account’s configured address — which is whatever you typed into the installer, possibly years and two email migrations ago. Mine pointed at an address I’d abandoned; the fix taught the cluster to be quiet, but this is what made the remaining mail count:

pveum user modify root@pam --email you@example.com

One honest caveat while we’re here: this post governs which notifications become email — it can’t prove your node can send email in the first place. Out of the box, a Proxmox node’s outbound mail path is often a polite fiction (on my cluster, it turned out only one of the four nodes could actually reach the outside world — a discovery that’s a story of its own). Giving every node a real mail path with msmtp and an app password is exactly what the msmtp + Gmail playbook walks through, copy-paste style.

Undo it in one command

Here’s where modified-builtin pays off. The builtin matcher can’t be truly deleted — so the delete call does something friendlier: it throws away your modifications and the stock builtin comes back, rules-free net and all.

pvesh delete /cluster/notifications/matchers/default-matcher

Run the get from the previous section afterward and you’ll see origin flip back to builtin — same as the day you installed. Every-backup emails and all. That symmetry is why I felt safe trying this on a cluster I care about: the entire experiment is one command in, one command out.

When one severity knob isn’t enough

The severity filter was my 95% fix, and I stopped there. But since you now know the matcher layer exists, it’s worth knowing how much further it goes — all documented in the same notifications chapter:

• Match by event type, not severity. A rule like match-field exact:type=vzdump will, in the docs’ words, “only match notifications about backups” — so you could route backup mail one way and everything else another.
• Match by calendar. Matchers support schedule rules, so “page me at night, digest me by day” is a config file away.
• Stack them. You can create as many matchers and targets as you like — separate emails per concern, a webhook for one event family, and so on. Each target is notified at most once per event, so overlapping matchers don’t double-send.

If your needs outgrow one knob, that’s the toolbox. Mine haven’t.

What’s next

My inbox now gets exactly two kinds of mail from the lab: failures, immediately — and nothing else. The next upgrade is turning “nothing else” into one email: a single daily digest that rolls up backups, disk space, updates, and anything that needs a human, so the cluster reports for duty once a day instead of never or constantly. That post is queued next — and the msmtp playbook that gives every node a working mail path to send it with is live now.

Until then: your backups are running nightly, you’ve proved they restore, and as of one command ago, the only backup email you’ll ever see again is the one that needs you. Check your matcher. Mine had been shouting into a drawer for months.

Related posts:

• Proxmox Backup Server: Automated CT and VM Backups with Deduplication — the nightly job generating all this mail; set it up first, then quiet it down here
• One UPS, Whole Homelab: Safe Auto-Shutdown with NUT — the same philosophy applied to power: automate the response, hear about it only when it matters
• What Is Prometheus? Homelab Metrics and Alerts Explained — where alerting graduates to next: metric thresholds instead of event emails
• What Is Grafana? Homelab Metrics and Dashboards Explained — dashboards you visit on your terms, the opposite of inbox push
• One Dashboard for Your Whole Homelab: Set Up Homepage — one glanceable page of lab status, so quiet email doesn’t mean flying blind
• Exit Code 137: Common Homelab Service Issues and Fixes — what to check when something does break and the error email arrives
• One Homelab, One Email: A Daily Digest You’ll Actually Read — the other half of this fix: where the silenced routine notices end up, with approve buttons
• The Email Flood Wasn’t Where I Looked — the field note where this exact flood first sent me chasing the wrong suspects

Sources: Proxmox VE — Notifications (Admin Guide), Proxmox VE — Backup and Restore (Admin Guide), Proxmox VE overview.