Do I need a paid email service to send homelab alerts?

No. A free Gmail account with an app password sends far more mail than a homelab ever generates. You only outgrow it if you start sending hundreds of alerts a day, which usually means the alerts themselves need fixing, not the sender.

Why aren't my Proxmox emails arriving?

Three usual causes. Root's email address is blank under Datacenter, Permissions, Users. The SMTP target uses your Google account password instead of an app password. Or no notification matcher routes the event to your SMTP target. Check all three in that order.

Should every service email me directly?

No. Route service uptime through Uptime Kuma so you get one consistent alert format and can silence maintenance windows in one place. Use Proxmox email for host and backup events, and Watchtower email for container updates. Three senders, one inbox.

What is the difference between a push monitor and an HTTP monitor?

An HTTP monitor polls a service and alerts when it stops answering. A push monitor is a dead man's switch: your script pings Uptime Kuma on success, and if the ping never arrives, you get alerted. Use HTTP for services and push for scheduled jobs.

Is email fast enough for outage alerts?

For a home setup, yes. Email lands within a minute or two, which is fine for a media server or a backup job. If you want an instant buzz on your phone, add a self-hosted ntfy channel alongside email rather than replacing it.

Homelab Email Notifications: Alerts From Uptime Kuma, Proxmox, and Docker

A homelab that fails quietly is worse than one that fails loudly. A media server can be down for a day before anyone notices. A backup job can stop running for three weeks, and you find out the night you actually need the backup. The fix is not checking dashboards every morning. It is getting your homelab to email you the moment something that matters breaks, so the rest of the time you can ignore it completely.

This guide wires up email alerts from the three layers of a budget homelab: your services (through Uptime Kuma), your hypervisor (through Proxmox), and your containers (through Docker and Watchtower). It slots directly onto the monitoring section of the homelab automation guide, which is where these alerts earn their keep, and it maps onto the same setup as my stack page: Proxmox on a mini PC, Docker containers, and a couple of cheap drives. Everything here is free. The only account you need is one you already have.

This guide contains no paid affiliate links. It is configuration, not shopping.

One Sender, One Inbox

Every system below needs to send email, and they can all send through the same account. So set that up first and reuse it everywhere.

The cheapest reliable option is a Gmail account with an app password. You do not want to hand your real Google password to a stack of homelab containers, and Google will not let you anyway if two-factor is on. An app password is a 16-character token scoped to sending mail. Revoke it and nothing else on the account is affected.

To create one:

Turn on 2-Step Verification on the Google account (required before app passwords exist)
Go to Google Account, Security, App passwords
Name it something like homelab-alerts and generate it
Copy the 16-character password. Google shows it once

Every service in this guide uses the same connection details:

Field	Value
SMTP host	`smtp.gmail.com`
Port	`587`
Encryption	STARTTLS
Username	your full Gmail address
Password	the app password, not your account password

A dedicated alerts account (say yourname.homelab@gmail.com) keeps homelab noise out of your personal inbox and gives you one address to forward or filter later. That is the only sender you need for the whole stack.

If you ever outgrow Gmail’s sending limits, a transactional relay with a free tier drops straight into the same fields. For a home setup you will not get close to that ceiling.

Layer 1: Service Alerts With Uptime Kuma

Uptime Kuma is the front line: it watches every service and tells you when one stops answering. Adding email takes two minutes.

In Uptime Kuma, go to Settings, Notifications, Add Notification. Choose Email (SMTP) and fill in the table above, plus:

From Email: your Gmail address
To Email: where you want alerts (can be the same address)

Click Test and confirm the message lands. Then, and this is the part people skip, check Default Enabled so the channel applies to every new monitor automatically. Without it, you add a monitor next month, forget to attach a notification, and it watches a service in silence.

Catch the jobs that fail silently

An HTTP monitor is great for a running service, but it cannot see a backup script that stopped executing. For that you need a push monitor, which flips the model: instead of Uptime Kuma checking your service, your job checks in with Uptime Kuma. If the check-in never arrives, you get an email.

Add a monitor of type Push. It hands you a URL. Append a curl to the end of any scheduled job so it only pings on success:

# Last line of your backup script, after the work succeeds
curl -fsS "https://uptime.yourdomain.com/api/push/AbCdEf123?status=up&msg=ok" > /dev/null

Set the monitor’s expected interval a little longer than the job’s schedule (26 hours for a daily job). If the script fails partway and exits on set -e, the ping never lands, and Uptime Kuma emails you that a job it expected to hear from went quiet. This single pattern catches the failure mode that quietly ruins homelabs. There is more on push monitors, keyword checks, and cooldowns in the advanced alerting guide.

Layer 2: Host Alerts With Proxmox

Uptime Kuma runs as a container, so it can only tell you about things while the host under it is alive. The hypervisor itself needs its own path to your inbox: failed backup jobs, storage filling up, a disk starting to fail. Proxmox 8 has a built-in notification system that sends these directly over SMTP, so you do not have to wrestle with Postfix relay config to get host mail working.

First, give Proxmox somewhere to send. Go to Datacenter, Permissions, Users, edit root@pam, and set the E-Mail field. The default notification target mails root, and if that field is blank, nothing goes anywhere.

Now add your SMTP sender. Go to Datacenter, Notifications, Add, SMTP:

Endpoint Name: gmail
Server: smtp.gmail.com
Encryption: STARTTLS
Port: 587
Username / Password: your Gmail address and the app password
From Address: your Gmail address
Recipient: add your alert address, or select the root user

Save, then use the Test button on the endpoint. A test mail should arrive within a minute.

Route the events you care about

Proxmox decides what goes where using notification matchers. The default matcher sends everything to the local mail-to-root target. To send events out through Gmail instead, add a matcher (Datacenter, Notifications, Add under Matchers) that targets your gmail endpoint. You can leave it matching everything at first, then tighten it later by severity or by field (for example, only backup events) once you know what is noisy.

Finally, make sure backup jobs actually use this. Edit each backup job under Datacenter, Backup, and set the Notification mode to use the notification system. Older Proxmox versions had a per-job email field with an “Always / On failure” toggle instead. Either way, the sane choice for a homelab is to hear about failures, not to get a green all-clear every single morning that you will train yourself to ignore.

The point of the host layer is the stuff you would otherwise never see coming: a vzdump backup that silently errored on a full disk, or a SMART warning three days before a drive actually dies.

Layer 3: Container Updates With Watchtower

The third layer is your containers. There are two questions here, and they have two answers.

“Is a container down?” is already covered. Uptime Kuma has a Docker Container monitor that checks whether a container is in the running state, and it emails through the channel you set up in layer 1. Point one at each critical container and you are done.

“Did a container just update?” is Watchtower’s job. If you run Watchtower to keep images current, you want a record of what it changed overnight, so a service that misbehaves after an update has an obvious first suspect. Watchtower emails through the same Gmail sender. Add these variables to its compose service:

services:
  watchtower:
    image: containrrr/watchtower:latest
    container_name: watchtower
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      WATCHTOWER_CLEANUP: "true"
      WATCHTOWER_SCHEDULE: "0 0 4 * * *"
      WATCHTOWER_NOTIFICATIONS: "email"
      WATCHTOWER_NOTIFICATION_EMAIL_FROM: "yourname.homelab@gmail.com"
      WATCHTOWER_NOTIFICATION_EMAIL_TO: "yourname.homelab@gmail.com"
      WATCHTOWER_NOTIFICATION_EMAIL_SERVER: "smtp.gmail.com"
      WATCHTOWER_NOTIFICATION_EMAIL_SERVER_PORT: "587"
      WATCHTOWER_NOTIFICATION_EMAIL_SERVER_USER: "yourname.homelab@gmail.com"
      WATCHTOWER_NOTIFICATION_EMAIL_SERVER_PASSWORD: "your-app-password"
      WATCHTOWER_NOTIFICATION_EMAIL_DELAY: "5"
      WATCHTOWER_NO_STARTUP_MESSAGE: "true"

Recreate the container:

docker compose up -d watchtower

By default Watchtower only emails when it actually updates something, which is what you want. WATCHTOWER_NO_STARTUP_MESSAGE suppresses the “I started up” mail so a container restart does not spam you, and WATCHTOWER_NOTIFICATION_EMAIL_DELAY gives it a few seconds so batched updates arrive as one message.

Keeping that app password out of a plaintext compose file is worth the extra step. Put it in an .env file next to the compose file (add the file to .gitignore) and reference it as ${WATCHTOWER_EMAIL_PASSWORD} instead of pasting the token inline.

Prove It Works Before You Trust It

An alerting setup you have not tested is a guess. Send one real message from each layer:

Layer	How to test
Uptime Kuma	The Test button on the notification channel
Proxmox	The Test button on the SMTP endpoint
Watchtower	Run `docker exec watchtower /watchtower --run-once` to force a check

Three emails, one inbox. Better still, cause a real failure once: stop a monitored container and wait for the down alert, then start it and confirm the recovery mail. Knowing the pipe works end to end is the entire reason you built it.

Keep the Signal Loud by Keeping It Rare

The fastest way to make alerts useless is to send too many. An inbox with forty “recovered” notices a day is an inbox you stop reading, and then you miss the one that mattered.

A few rules that keep it honest:

Alert on failure, not on success. You do not need a nightly email confirming the backup ran. You need one the night it does not.
Use maintenance windows. Before a planned reboot, set an Uptime Kuma maintenance window so a deliberate outage does not fire alerts.
Set resend cooldowns. For a flapping service, configure Uptime Kuma to remind you every few hours while it is down rather than every 60 seconds.
Filter at the inbox. A Gmail filter that labels everything from your alerts address and stars anything containing “down” or “failed” turns the raw stream into a glanceable queue.

Do that, and a quiet inbox genuinely means a healthy homelab. When it buzzes, it is worth reading.

Where This Fits

Email notifications are the layer that makes every other automation trustworthy. A backup job, an update schedule, a monitored service: none of them are real until they can reach you when they break. Wire this up once and your homelab stops being something you check on and becomes something that checks in with you.

For the full picture of scheduled backups, automatic updates, and monitoring working together, see the homelab automation guide. To push Uptime Kuma beyond simple checks into SSL expiry, keyword, and API monitoring, the advanced alerting guide covers the rest. And if you are still assembling the container side of this, Docker Compose basics and the best self-hosted apps for beginners are the place to start.