Why the default setup doesn’t actually notify you

Fresh Proxmox installs ship with a mail-to-root notification target wired to the smtp-default relay, which on a typical homelab node means local sendmail trying to deliver to root@<hostname>, a mailbox nobody reads, going out through a mail transport that was never configured to actually relay anywhere. The notification system isn’t broken; it’s just configured to shout into a room with nobody in it. The fix isn’t learning a new system, it’s pointing the one that’s already there at somewhere you’ll actually see it.

The two pieces: targets and matchers

Proxmox’s notification system (Datacenter > Notifications in the GUI, or pvesh and the /etc/pve/notifications.cfg file underneath it) splits into two separate concepts, and understanding the split is most of what makes the rest of the configuration make sense.

Targets are destinations: where a notification actually gets sent. Proxmox supports several target types out of the box:

• SMTP - standard email via an external relay (Gmail, a real SMTP provider, or your own mail server), not the local sendmail-to-root default.
• Sendmail - local MTA delivery, the legacy default, fine only if you’ve actually got mail flowing somewhere from this host already.
• Webhook - a generic HTTP POST with a configurable URL, headers, and body template, which is the one that matters most because it’s the bridge into everything else: Slack, Discord, ntfy, Gotify, a Home Assistant automation, or any other endpoint that accepts a webhook. Discord and Slack both take a webhook target directly once you format the body to match what they expect.
• Gotify - a dedicated target type for self-hosted Gotify push notifications, no generic webhook wrapping needed.

Matchers are rules: which events, at which severity, get routed to which target. A matcher can filter on the notification’s metadata (the calling service, like backup or replication), on severity (info, warning, error), and on time windows if you don’t want 3 AM alerts for things that self-heal. Without a matcher pointed at it, a target configured but unused does nothing, which is a common first mistake: adding a webhook target, confirming the test notification worked, and never actually building the matcher that routes real events to it.

Setting up a target that reaches you

For most homelabs, a webhook into something you already have open (Discord, ntfy, a Gotify app on your phone) beats email, since email requires its own working relay as a prerequisite and most homelab nodes don’t have one configured for anything else. ntfy in particular is close to zero-setup: self-host it or use the public instance, pick a topic name, and a webhook target with a plain POST to https://ntfy.sh/<your-topic> (or your own instance) with the message in the body gets a push notification to your phone’s ntfy app with no API key or account needed.

From the GUI: Datacenter > Notifications > Add > Webhook, give it a name, the target URL, and a body template. Proxmox’s webhook body supports placeholders for the notification title and message text, so the template just needs to map those into whatever JSON shape the destination expects, a single {"text": "{{ title }}: {{ message }}"} style body is enough for Discord, Slack, and ntfy’s JSON publish format alike, with minor field-name differences between them (Discord wants content, Slack wants text, ntfy accepts either plain text or its own JSON schema). Test it with the GUI’s built-in “Send test notification” button before building anything on top of it. If the test doesn’t arrive, the problem is almost always the URL or the field name in the body template, not Proxmox’s side of the pipe.

For Discord specifically: create a webhook in the target channel’s integration settings, copy the webhook URL Discord gives you, and use that directly as the target URL with a body of {"content": "{{ title }}: {{ message }}"}.

Setting up a matcher that actually routes something

A matcher with no filters catches everything, which is a reasonable starting point for a homelab where “everything” is a manageable volume: backup job results, replication job results, and cluster health events. From Datacenter > Notifications > Add Matcher, point it at the target created above, leave the calling-service filter open initially, and optionally add a severity filter so routine info-level success notifications don’t bury the warning and error ones you actually care about on a busy day.

Once the volume of notifications makes that noisy, which happens fast on a cluster with several nightly backup jobs, tighten it: a matcher scoped to calling service backup with severity warning or higher catches failed and partially-failed backups without also pinging you every time a backup job finishes normally. A second matcher on calling service replication catches the silently-failing replication job scenario covered in this site’s storage replication article, which is exactly the kind of failure this whole system exists to surface before the RPO gap grows for days unnoticed.

What’s actually wired into this system

The notification system isn’t just for backups. It’s the same pipe behind:

• Backup job results - success, failure, and partial failure (some guests backed up, others skipped or errored) all generate distinct notifications.
• Replication job failures - exactly the silent-failure mode called out as the biggest practical risk of relying on pvesr for near-HA.
• Cluster and node health - fencing events, a node dropping out of quorum, and other cluster-level state changes that otherwise only show up if you happen to be looking at the GUI at the right moment.
• Package updates available - a periodic check-in, lower priority but useful for not drifting too far behind on patches, especially relevant given the upgrade-lifecycle gotchas covered in this site’s Proxmox upgrade article.

Each of these fires with its own calling-service identifier, which is what matchers filter on, so a homelab running one node with light backup needs and a homelab running a three-node cluster with replication and HA can both use the same underlying system, just with different matcher scopes.

A sane homelab setup, end to end

For a typical single-node or small-cluster homelab, this is the whole thing in practice:

1. Pick one low-friction target type (ntfy if you want zero email infrastructure, a Discord webhook if you’re already living in a Discord server for the homelab).
2. Add that target, test it, confirm the notification actually arrives on the device you’ll notice it on.
3. Add a matcher scoped to backup and replication (if applicable) at warning severity and above, pointed at that target.
4. Add a second, broader matcher at error severity only, with no calling-service filter, as a catch-all for anything else that goes seriously wrong that the narrower matcher didn’t anticipate.
5. Leave the default mail-to-root target alone rather than deleting it; it’s harmless if nothing routes to it, and removing built-in defaults tends to cause more confusion later than leaving an unused one in place.

That’s a complete alerting setup for the two failure modes that actually bite homelabs silently: a backup job that’s been failing for a week because a target disk filled up, and a replication job that stopped syncing because a node was briefly unreachable and nobody noticed the retry never caught up. Both of those are a five-minute notification setup away from being a phone buzz instead of a surprise during the actual outage.

Bottom line

The Proxmox notification system is already installed, already wired to every backup and replication job on the host, and already failing to reach anyone by default because it’s pointed at a mailbox nobody reads. Pointing one webhook target at something you’ll actually see, and one or two matchers at the events that matter, converts every other “remember to check the GUI” caveat in this site’s Proxmox coverage from a manual habit into something that just taps you on the shoulder when it’s actually needed.