Proxmox Node Monitoring Alerting Self-Hosted: The Reliable PVE and PBS Guide

proxmox-node-monitoring-alerting-self-hosted.md
title Proxmox Node Monitoring Alerting Self-Hosted: The Reliable PVE and PBS Guide
date
author VahaC
read 13 min read
category Self-Hosting
tags #container #Homelab #Linux #Proxmox #Stashboard
proxmox node monitoring alerting self-hosted

Proxmox node monitoring alerting self-hosted is the part of a homelab you only miss once: the night a pool fills up, a fan dies or an SSD runs out of spare blocks. Stashboard V6.8 turned the node row on its Proxmox page into a live health card with a detailed modal, V6.8.1 added threshold alerts, and V6.8.2 added SSH collectors plus Proxmox Backup Server (PBS) support. 🩺

This guide walks the whole Proxmox node monitoring alerting self-hosted chain, from the card to your phone, with setup, verification and limits. New to Stashboard’s Proxmox side? Start with the Proxmox pillar guide.

What Proxmox Node Monitoring Alerting Self-Hosted Covers

Each connected host is one node, and everything hangs off its card:

  • Node card: live CPU, RAM and root-disk chips, coloured ok, warn or crit.
  • Node modal: Overview, CPU / RAM, Storage / SMART, Network, Sensors, Alerts and Console tabs.
  • Deep telemetry: SSH collectors for per-core CPU, disk IO, thin pools, per-NIC traffic, SMART self-tests and sensors.
  • Alerting: six categories scored against warn/crit thresholds every five minutes, with debounce.
  • Delivery: email, Telegram, Apprise and a Home Assistant problem sensor.

The API token alone drives the card, most of the modal and four of the six alert categories; Proxmox node monitoring alerting self-hosted needs SSH for deep telemetry, temperatures and NIC errors.

Prerequisites

Line these up before you switch on Proxmox node monitoring alerting self-hosted:

  • Stashboard 6.8.2 or newer. PBS disk fixes need 7.2.1, the MQTT sensor 9.1 and Apprise 10.0, so any current 10.x image has it all.
  • An API token. On PVE, PVEAuditor on / covers every read here; the host form’s How to create an API token link walks you through it. A new PBS token has no permissions until you grant it Audit (PBS user management).
  • SSH as root with a key. Collectors run as the SSH user without sudo, and smartctl and lvs need root.
  • lm-sensors on the node; smartmontools ships with PVE and PBS.
  • A notification channel: SMTP (Stashboard SMTP setup), a Telegram bot or an Apprise API endpoint.

Tokens, keys and sensors

On a PBS host, create the token (the secret prints once) and grant read-only rights:

proxmox-backup-manager user generate-token root@pam stashboard
proxmox-backup-manager acl update / Audit --auth-id 'root@pam!stashboard'

Keep the single quotes, or bash expands the !. Then create a dedicated SSH key and authorize it on the node:

ssh-keygen -t ed25519 -f ./stashboard_node -C stashboard
ssh-copy-id -i stashboard_node.pub [email protected]

On the node, install lm-sensors; if sensors shows nothing, run sensors-detect (manual):

apt install lm-sensors
sensors

⚠️ This is a root key for your hypervisor. It controls every guest, and on a PVE cluster root’s authorized_keys is usually shared across nodes via /etc/pve/priv/authorized_keys. Never reuse your personal key; Stashboard stores this one encrypted.

The Node Card: Health at a Glance

Each host on the Proxmox page opens with a full-width node card, the first layer of Proxmox node monitoring alerting self-hosted:

  • A status dot in the worst chip’s colour, the update badge and an online / offline pill.
  • node or PBS node, the API URL and uptime.
  • CPU, RAM and Root chips: amber from 80, 85 and 85 %, red from 95 %.
  • Refreshed Xs ago; the card polls about every 20 seconds.

Hover an amber or red chip for the reason and a suggested action. Click the card for the modal, use the icon row to open a tab directly, or right-click for the tabs plus Check now and Update now. The card always uses the global defaults; per-node overrides only affect alerting.

Inside the Node Modal

The modal is where Proxmox node monitoring alerting self-hosted gets detailed; each tab loads when opened:

  • Overview: uptime, kernel, version, subscription, CPU model, load, IO wait, RAM, swap and root filesystem. SSH adds CPU steal (⚠ from 5 %) and Available memory from MemAvailable, truer than the API’s free.
  • CPU / RAM: per-core bars (SSH), a 2-second Live view with Pause, and RRD History by hour, day or week.
  • Storage / SMART: pool meters (datastores on PBS), thin-pool fill, a Disk IO table and each disk’s SMART health and wearout. Expand a disk for its last self-test, the Reallocated, Pending, Uncorrectable and Power-on hrs counters and every attribute; SMART is re-read at most hourly unless you click Refresh now.
  • Network: last-hour throughput plus each interface’s state, speed, duplex, rates, errors and drops.
  • Sensors: temperatures against each chip’s own limits, fans, voltages and power.
  • Alerts (below) and Console, a root shell behind its own gates.

Wearout here is life remaining (100 % = new); the Proxmox web UI shows wear used. Live tabs refresh every 20 s by default (5–300 s per host), backing off while the host is unreachable.

Deep Telemetry: What the SSH Collectors Run

The API reports aggregates, so Proxmox node monitoring alerting self-hosted gets the detail from read-only SSH collectors, one command each behind a capability check. A missing tool yields a not available note, never an error, and rate-based collectors take two samples a second apart:

  • CPU and memory: /proc/meminfo plus two /proc/stat samples give per-core busy %, steal and MemAvailable.
  • Disk IO: two /proc/diskstats samples give throughput, IOPS and wait per whole disk (kernel I/O stats).
  • Thin pools: lvs --reportformat json, useful if you added LVM-thin storage.
  • Network: two /proc/net/dev samples plus /sys/class/net give rates, errors, drops and link state.
  • SMART self-test: smartctl -l selftest -A when you expand a disk (smartctl manual).
  • Sensors: sensors -j, run exactly like this:
if command -v sensors >/dev/null 2>&1; then sensors -j 2>/dev/null; else echo NOSENSORS; fi

Sessions time out after 15 seconds to connect and 30 to run, so a hung node can’t stall the dashboard. For SMART history, add Scrutiny on a Proxmox LXC.

How Proxmox Node Monitoring Alerting Self-Hosted Scores a Node

On each evaluation, Proxmox node monitoring alerting self-hosted classifies six categories (defaults below, boundaries inclusive):

  • CPU (API): warn 80 %, crit 95 %.
  • Memory (API): used RAM, 85 / 95 %.
  • Storage (API): the fullest of the root filesystem and every active storage, 85 / 95 %. NFS or PBS storages attached to a PVE node count too, as does every PBS datastore.
  • Thermal (SSH): the hottest sensor against its chip’s own high and crit limits, else 80 / 90 °C.
  • SMART (API): health other than PASSED or OK is crit; SSD life remaining at or below 20 % warns, at or below 10 % is crit.
  • Network (SSH): the rise in rx_errs + tx_errs on physical NICs since the last evaluation, +10 warn, +100 crit. Drops are ignored since V6.8.2, because on a bridged node they climb harmlessly.

An unavailable source (no SSH, no lm-sensors, a missing API field) is n/a: it never alerts and never clears. The first network reading only sets a baseline, and a reboot’s counter reset counts as zero.

Debounce, recovery and the per-category breakdown

Evaluation runs on every background tick, about every five minutes, whatever the host’s update schedule. A category must breach on three consecutive evaluations to fire (about 15 minutes); a warn↔crit change or a recovery also needs three readings, and the first-seen time survives an escalation.

In Proxmox node monitoring alerting self-hosted, the result is a per-category verdict of ok, warn or crit, and the node’s overall verdict is the worst of them. The Alerts tab lists each active category with its metric, value, threshold and since time, refreshing every 30 seconds. Two container environment variables tune the tick and the debounce count (the tick can’t go below 30 seconds):

STASHBOARD_ProxmoxUpdate__TickIntervalSeconds: "300"
STASHBOARD_ProxmoxUpdate__AlertConsecutiveBreaches: "3"

How Proxmox Node Monitoring Alerting Self-Hosted Delivers Alerts 🔔

Alerts go out as one digest per host listing every active category. Proxmox node monitoring alerting self-hosted re-sends only when that set changes: a new category, a warn↔crit change, a clear, or the final all-clear. A steady alert pings once even as its value wiggles, a V6.8.2 fix. A Telegram digest looks like this:

🔴 Node health alert on Proxmox host home-pve
• Memory CRITICAL — RAM at 96% (threshold 95%), since 2026-10-22 07:05 UTC
• Thermal WARNING — Package id 0 at 84°C (threshold 80°C), since 2026-10-22 07:20 UTC

Each channel has its own switch and throttle, so a broken SMTP server never blocks Telegram, and a failed send retries on the next tick:

  • Email: the host’s Email me when updates appear box plus SMTP. Subjects read [Stashboard] Node health alert on home-pve, then [Stashboard] home-pve node health recovered.
  • Telegram: bot token and chat ID in Settings → Notifications with Send notifications when a service becomes unavailable ticked (the master switch, despite its label), plus the host’s Also notify via Telegram.
  • Apprise (V10.0): a base URL and Apprise URLs in Settings → Notifications, then the host’s Also notify via Apprise, greyed out until configured. Crit is sent as failure, warn as warning, the all-clear as success.
  • Home Assistant (V9.1): with MQTT on in Settings → Home Assistant, each evaluated node gets a binary sensor with device_class: problem, on for warn or crit. Its attributes carry the per-category breakdown: worst_severity, cpu, memory, storage, thermal, smart, network and detail.

⚠️ The email switch is shared. Its label mentions updates, but unticking it also stops node-alert email.

Set Up Proxmox Node Monitoring Alerting Self-Hosted Step by Step

With the prerequisites done, Proxmox node monitoring alerting self-hosted takes about five minutes per host:

  1. Open the host form: Add Proxmox host, or ⋮ → Edit on an existing host.
  2. Pick the server type: Proxmox VE (port 8006) or Proxmox Backup Server (port 8007).
  3. Fill in the API section: base URL, node name, token ID (root@pam!stashboard) and secret. Keep Skip TLS certificate validation on for a self-signed certificate.
  4. Fill in SSH: host, port 22, user root, the full private key including its -----BEGIN and -----END lines, and any passphrase. The PVE form’s hint still says SSH only powers per-LXC apt counts; it feeds every collector too.
  5. Set refresh and channels: leave Live telemetry refresh blank for 20 s, keep Enabled (scan on schedule) ticked (only enabled hosts are evaluated) and tick your channels.
  6. Click Test connection: expect API reachable and SSH reachable, then save.
  7. Enable alerting: on the Alerts tab, tick Node health alerting enabled. It saves at once; every node starts muted.
  8. Tune categories and thresholds: blank fields use the placeholder defaults; overrides take 1–100 % and 1–150 °C, warn below crit. SMART wearout and NIC deltas are fixed. Give a node that runs hot by design its own numbers instead of muting it.
  9. Click Save thresholds. ⚠️ It’s the tab’s only save button and also saves the category checkboxes; close the modal without it and unticked categories stay on.

Proxmox Backup Server: What’s Different

On a PBS host, Proxmox node monitoring alerting self-hosted gives you the same card, modal and alerts, with these differences:

  • Auth: PBS joins token ID and secret with : in a PBSAPIToken header, PVE with = in PVEAPIToken; adding a PBS host as PVE gets you a 401.
  • No guests: node status doubles as the auth probe, and the card reads PBS node.
  • Datastores: /status/datastore-usage replaces pools in the Storage tab and alert.
  • SMART: PBS wants bare disk names (sda) and different field names; 7.2.1 handles both, while older builds show disks as unknown.
  • SSH powers sensors, NIC-error alerts, Update now and the console.

Building one? See the dedicated Proxmox Backup Server setup guide.

How to Verify Your Proxmox Node Monitoring Alerting Self-Hosted Setup

Prove Proxmox node monitoring alerting self-hosted end to end before trusting it:

  1. Cross-check the card against pvesh get /nodes/pve/status --output-format json-pretty (your node name), and Sensors against sensors.
  2. Check the SSH tabs: per-core bars on CPU / RAM, live rates on Network.
  3. Force a test alert: on Alerts, set RAM to warn 1 and crit 2, click Save thresholds, then Check now three times. Each click is one evaluation, so the third fires: Memory · RAM shows critical and the 🔴 digest arrives.
  4. Clear it: empty both fields, save and click Check now three more times for No active alerts and a ✅ recovery message.
  5. Check Home Assistant: the problem sensor flips on, then off.

⚠️ Don’t leave the test override in place. A node stuck at critical sends nothing new, so a real memory problem would hide behind it.

Troubleshooting

Most Proxmox node monitoring alerting self-hosted problems are a missing source or a switch:

  • lm-sensors isn’t installed: install it. No temperature or fan sensors were detected means run sensors-detect, or the node is a VM without sensors.
  • Tabs ask for SSH credentials: SSH is missing or failing; Test connection says which.
  • Alerts never fire: check the alerting toggle, Enabled (scan on schedule) and the category ticks; Thermal and Network need SSH.
  • A SMART alert never clears: a disk reporting UNKNOWN, such as a USB drive or one behind a RAID controller, counts as crit. If it can’t report, untick SMART.
  • An alert outlives its category: unticking stops evaluation but doesn’t clear the state. Re-tick, let it recover, then untick.
  • No message arrived: check the host’s channel boxes, Telegram’s master checkbox and the Apprise config; each channel fails on its own, so check the logs.

Risks of Proxmox Node Monitoring Alerting Self-Hosted

Know where Proxmox node monitoring alerting self-hosted stops:

  • It isn’t an uptime monitor. An unreachable node makes every source n/a, so nothing fires and active alerts freeze. Watch the node’s web UI with a Stashboard service check that has offline notifications on.
  • SMART checks can wake sleeping HDDs. Each evaluation reads the API disk list, and Proxmox VE runs smartctl -H on every disk to fill its health column. If you spin drives down, expect wake-ups or untick SMART.
  • Alerts lag by design. Three evaluations take about 15 minutes; hardware thermal limits protect the CPU, not a dashboard.
  • The key is root. Protect it, and limit who can edit hosts in Stashboard.
  • Live tabs cost a little. Each open tab starts short SSH sessions per refresh; raise the interval on a busy node.

Proxmox Node Monitoring Alerting Self-Hosted FAQ

Does Proxmox node monitoring alerting self-hosted need SSH?

Not for CPU, memory, storage and SMART alerts, which use the API token. Thermal and Network alerts and all deep telemetry need SSH.

Will a steady alert spam me?

No. You get one message when it fires, one on a warn↔crit change and one when it clears.

Can I set different thresholds per node?

Yes. CPU, RAM, storage and temperature take per-node overrides; blank fields use the global defaults.

Bottom Line

Proxmox node monitoring alerting self-hosted in Stashboard gives every PVE and PBS node a live card, a seven-tab modal, SSH telemetry the API can’t provide, and debounced alerts that reach you only when something changes. Add a root key, tick Node health alerting enabled, fire one test alert, and let Proxmox node monitoring alerting self-hosted watch the hardware under your guests. 🚀

Stashboard is open source: code on GitHub, image on Docker Hub.

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.