Complete Guide: Scrutiny SMART Monitoring on Proxmox LXC in 6 Steps

If you run a homelab with more than a couple of drives, you already know the pain: smartctl works but its output is a wall of numbers, smartd sends cryptic emails, and nobody tracks attribute changes over time out of the box. That last part is crucial — a drive usually does not die suddenly; it degrades. Today I’ll walk you through setting up Scrutiny SMART monitoring on Proxmox LXC — a beautiful self-hosted dashboard that shows drive health, historical trends, and sends alerts before a disk fails. 🛡️

This guide covers Scrutiny SMART monitoring on Proxmox from scratch — including all the real-world pitfalls that cost me hours and that you won’t find in the official docs. By the end, Scrutiny SMART monitoring on Proxmox will be fully running with Telegram alerts.

We’ll use the official Hub-Spoke architecture (recommended by the Scrutiny maintainers): the Web UI and database run safely inside an unprivileged LXC, while a tiny collector binary runs on the Proxmox host itself — the only place where it has direct, low-level access to your drives.

Why Scrutiny SMART Monitoring on Proxmox Is Worth It

Before diving in, let me explain why Scrutiny SMART monitoring on Proxmox solves real problems that the built-in tools cannot. The built-in smartd daemon has several known limitations, documented by the Scrutiny project itself:

It does not differentiate between critical and informational SMART attributes.
It does not record history, so slow attribute degradation is invisible.
Manufacturer thresholds are often set so high that they only trigger after a drive has already failed.
It is command-line only — no dashboard for your headless server.

Scrutiny solves all of this. It cross-references manufacturer SMART values with Backblaze real-world failure rates, giving you a much more realistic view of drive health. You see temperature trends, power-on hours, reallocated sectors, wear leveling — all on one dashboard. And of course, Scrutiny SMART monitoring on Proxmox means you can watch over SATA SSDs, HDDs, and NVMe drives equally.

Why the Hub-Spoke Architecture, Not Omnibus in LXC

This is the most important design decision. You might be tempted to throw everything in a single LXC with disk passthrough — don’t. Here’s why:

Unprivileged LXC (the secure default) cannot easily read SMART data from passed-through devices. Block devices appear as nobody:nogroup, and smartctl returns Operation not permitted. This has been a consistent pain point on the Proxmox forum for years.
NVMe drives specifically require the SYS_ADMIN capability, which is not trivial (and undesirable) to grant to an unprivileged container.
Privileged LXC would work, but it defeats the security model — you’d be running a web-facing service with essentially root access to the host.

The clean solution is Hub-Spoke:

Hub — Scrutiny Web UI + InfluxDB → runs inside an unprivileged LXC with Docker. Safe, isolated, no disk passthrough needed.
Spoke (Collector) — a small binary that runs on the Proxmox host itself, where it has native access to /dev/sda, /dev/nvme0, etc. It reads SMART data and sends it to the Hub via HTTP.

This is exactly the setup I’ll show you now. ⚙️

What You’ll Need

Before starting with Scrutiny SMART monitoring on Proxmox, make sure you have:

A working Proxmox VE 8.x or 9.x host with some drives (SATA, NVMe — doesn’t matter).
Basic shell access to the Proxmox host.
A local network where the LXC can reach the host (usually the case by default).
About 15–20 minutes of your time.

If you haven’t done post-install cleanup on your Proxmox yet, I strongly recommend doing that first — it’ll save you headaches later. I covered it in my Proxmox VE Post Install Script guide. And if you’re setting up Proxmox from scratch, check out Install Proxmox VE 9.1.

Step 1: Create the Docker LXC (The Hub)

The Hub is the brain of our Scrutiny SMART monitoring on Proxmox setup — it runs the Web UI and InfluxDB database. We need an LXC with Docker installed for this. The fastest, cleanest way is via the Community Scripts project — it creates a pre-configured Debian LXC with Docker already set up. 🐳

On your Proxmox host shell, run:

bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/docker.sh)"

⚠️ Security note: community scripts run as root on your host. Always skim them before executing. The Docker script is well-known and widely used, but the principle stands.

During the prompts:

Choose Advanced mode if you want custom settings.
Give it 2 CPU cores, 1–2 GB RAM, 8–10 GB disk — this is plenty for Scrutiny + InfluxDB.
Leave it unprivileged (this is the secure default).
Set a static IP if you can — you’ll point the collector at it later.

Once the container is created and running, enter it:

pct enter <CTID>

Replace <CTID> with the ID assigned to your new container (e.g. 150). You can also just use the Proxmox web UI console.

Verify Docker Works

docker --version
docker compose version

You should see both working. If not, the helper script likely failed partway — check its output.

Step 2: Deploy Scrutiny Web + InfluxDB with Docker Compose

This step sets up the Hub — the central component of Scrutiny SMART monitoring on Proxmox that stores all your drive data and serves the web UI. Inside the LXC, create the working directory and navigate into it:

mkdir -p /opt/scrutiny && cd /opt/scrutiny

2a. Create the Scrutiny config file first ⚠️

This step is critical — scrutiny-web must have a config file before it starts. Without it, the app panics trying to build the InfluxDB connection URL from empty values. Create it now:

mkdir -p /opt/scrutiny/config

cat > /opt/scrutiny/config/scrutiny.yaml << 'EOF'
version: 1

web:
  listen:
    port: 8080
    host: 0.0.0.0
  database:
    location: /opt/scrutiny/config/scrutiny.db
  src:
    frontend:
      path: /opt/scrutiny/web

  influxdb:
    host: influxdb
    port: 8086
EOF

2b. Create docker-compose.yml

This is based on the official example.hubspoke.docker-compose.yml — Hub components only (Web + InfluxDB). The collector will live on the Proxmox host.

cat > /opt/scrutiny/docker-compose.yml << 'EOF'
services:
  influxdb:
    image: influxdb:2.8
    container_name: scrutiny-influxdb
    restart: unless-stopped
    ports:
      - "8086:8086"
    volumes:
      - ./influxdb:/var/lib/influxdb2
    networks:
      - scrutiny-net
    healthcheck:
      test: ["CMD", "influx", "ping"]
      interval: 10s
      timeout: 5s
      retries: 10

  scrutiny-web:
    image: ghcr.io/analogj/scrutiny:v0.8.6-web
    container_name: scrutiny-web
    restart: unless-stopped
    ports:
      - "8080:8080"
    volumes:
      - ./config:/opt/scrutiny/config
    depends_on:
      influxdb:
        condition: service_healthy
    networks:
      - scrutiny-net

networks:
  scrutiny-net:
    driver: bridge
EOF

Three things to note about this compose vs. what you might find in other guides:

Pin version v0.8.6 — do not use master-web or latest. The web UI and the collector binary must be the exact same version. As of writing, v0.8.6 is the last stable combination that works correctly. Version v0.9.0-web has a breaking change where /api/devices/register silently returns {"success":false}, so drives never appear on the dashboard.
No env vars for InfluxDB — Scrutiny reads the connection from scrutiny.yaml. Env vars like SCRUTINY_WEB_INFLUXDB_HOST look logical but are silently ignored, causing a startup panic.
healthcheck + condition: service_healthy — scrutiny-web waits until InfluxDB is genuinely ready, not just launched. Without this, web starts too early and crashes.

2c. Start the stack

docker compose up -d

Wait ~20 seconds for InfluxDB to pass its healthcheck, then verify:

docker compose logs scrutiny-web

You should see:

Successfully connected to scrutiny sqlite db
Database migration completed successfully

No panic lines — you’re good. 🎉 Open http://<LXC_IP>:8080 in your browser. The Scrutiny dashboard should load — empty for now, no collector has reported yet. That’s exactly what we’re fixing next. 🚀

Step 3: Install the Scrutiny Collector on the Proxmox Host

Now the key part of Scrutiny SMART monitoring on Proxmox — the collector lives on the Proxmox host itself.

Exit the LXC and get back to the Proxmox host shell. Install smartmontools (usually already present, but just in case):

apt install smartmontools -y

Create a directory for the collector and download version v0.8.6 — this must match the web image version exactly:

mkdir -p /opt/scrutiny/bin /opt/scrutiny/config

wget -O /opt/scrutiny/bin/scrutiny-collector-metrics \
  https://github.com/AnalogJ/scrutiny/releases/download/v0.8.6/scrutiny-collector-metrics-linux-amd64

chmod +x /opt/scrutiny/bin/scrutiny-collector-metrics

⚠️ Version pinning is critical. The collector and the web UI must run the exact same version. Using releases/latest will likely give you v0.9.0 which has a breaking API change — devices will never appear on the dashboard even though everything seems to work. Always download a specific matching version tag.

Verify the version after download:

/opt/scrutiny/bin/scrutiny-collector-metrics --version

Expected output: linux.amd64-0.8.6

3a. Create collector.yaml ⚠️

This step is critical for cron to work. Skipping it is the most common reason why Scrutiny SMART monitoring on Proxmox appears to work manually but fails silently when run via cron. When cron runs the collector, it uses a minimal PATH that does not include /usr/sbin — so smartctl is not found and the collector silently fails with DependencyMissingError: "smartctl binary is missing".

The fix is to specify the full path to smartctl in a config file:

cat > /opt/scrutiny/config/collector.yaml << 'EOF'
version: 1
commands:
  metrics_smartctl_bin: /usr/sbin/smartctl
host:
  id: "proxmox-main"
EOF

The host.id field labels your host on the dashboard — useful when you add multiple hosts (e.g. OMV) later.

3b. Test run

/opt/scrutiny/bin/scrutiny-collector-metrics run \
  --api-endpoint "http://<LXC_IP>:8080"

You should see it detect your drives one by one and post the data. Refresh the Scrutiny dashboard — your drives should now appear. 🎉

If some drives are missing or show as “unknown,” the collector probably couldn’t auto-detect their device type. You can override this in collector.yaml (more below in Troubleshooting).

Step 4: Schedule the Collector with Cron

One run is nice, but for historical trends we need the collector to run on a schedule.

⚠️ Always edit the root crontab — the collector needs root privileges to read SMART data. On systems where you log in as a non-root user (like OMV where you log in as pi), always use sudo crontab -e, never just crontab -e. If you add the job to a regular user’s crontab, smartctl will fail silently with a permission error.

On the Proxmox host (already root):

crontab -e

On OMV or other hosts (non-root user):

sudo crontab -e

Add a line that runs the collector every 30 minutes:

*/30 * * * * /opt/scrutiny/bin/scrutiny-collector-metrics run --api-endpoint "http://<LXC_IP>:8080" >/dev/null 2>&1

My recommendation on frequency:

Every 30 minutes is a good balance — frequent enough for temperature trends, light on InfluxDB.
Every 15 minutes if you want finer granularity.
Every hour if you want to keep InfluxDB small.

Verify the crontab was saved correctly:

# On Proxmox host
crontab -l

# On OMV or non-root hosts
sudo crontab -l

And verify cron daemon is running:

systemctl status cron

Done. Your Scrutiny SMART monitoring on Proxmox is now fully functional. After a few hours you’ll start seeing temperature curves and power-on-hour trends. 📈power-on-hour trends. 📈

Step 5: Configure Telegram Notifications (Optional but Highly Recommended)

What’s the point of Scrutiny SMART monitoring on Proxmox without alerts? Scrutiny supports notifications through a lot of channels — Email, Discord, Gotify, Slack, Telegram, Webhooks, and more, via the shoutrrr library.

Since you (like me) probably already have a Telegram bot set up (I used one for my CrowdSec + Nginx Proxy Manager on HAOS setup), we’ll reuse that bot here.

We already created /opt/scrutiny/config/scrutiny.yaml in Step 2. Now we just add a notify block to it. Inside the LXC:

cat >> /opt/scrutiny/config/scrutiny.yaml << 'EOF'

notify:
  urls:
    - "telegram://BOT_TOKEN@telegram?chats=CHAT_ID"
EOF

RReplace:

BOT_TOKEN — your Telegram bot token (e.g. 1234567890:AAHd...).
CHAT_ID — your chat or channel ID where alerts should arrive.

🔍 The Telegram URL format for shoutrrr is very specific. Full documentation: containrrr.dev/shoutrrr/services/telegram. Note the @telegram literal — it is required.

Restart the web container to pick up the change:

cd /opt/scrutiny && docker compose restart scrutiny-web

Controlling notification level via Settings UI 🔔

⚠️ Do not add notify.level to scrutiny.yaml — in v0.8.6 this option is deprecated and causes the container to crash with a ConfigValidationError on every startup.

Notification settings are configured through the web UI. Open http://<LXC_IP>:8080 → click Settings (top right). The relevant fields are:

Notify – Filter Attributes — controls which attribute types trigger alerts: All, Critical.
Repeat Notifications — by default set to Always, meaning you will get an alert on every collector run where a drive has a problem. With a 15-minute cron this can get noisy fast. Change it to Only when the value has changed — this way alerts fire only when a SMART attribute actually worsens, not on every scan.

To test that notifications work, run the collector manually on the Proxmox host:

/opt/scrutiny/bin/scrutiny-collector-metrics run --api-endpoint "http://<LXC_IP>:8080"

If a drive has a Warning or Failed status, a Telegram message should arrive within seconds. 📬

Step 6: Verify Everything Is Working

Let’s do a full sanity check of your Scrutiny SMART monitoring on Proxmox installation:

Dashboard reachable at http://<LXC_IP>:8080 — ✅
All drives detected — you see every SATA/NVMe drive from your Proxmox host on the dashboard.
Green health status for each drive (unless one is actually failing — in which case, hurray, you caught it!).
Cron job running — grep scrutiny /var/log/syslog on the host should show periodic executions.
Fresh “Last Updated” timestamp — within your cron interval.
Test notification received via Telegram.

If all six pass, you’re done. Close this tab and go do something fun. 🎮

Troubleshooting Scrutiny SMART Monitoring on Proxmox

A Drive Is Missing or Shows “Unknown”

If drives disappear or never show up after setting up Scrutiny SMART monitoring on Proxmox, the collector likely cannot auto-detect the device type.

Some drives — especially those behind USB enclosures or SAS/RAID controllers — need an explicit type hint. Create a collector config on the Proxmox host:

mkdir -p /opt/scrutiny/config
nano /opt/scrutiny/config/collector.yaml

Example:

version: 1
host:
  id: "proxmox-main"
devices:
  - device: /dev/sda
    type: 'sat'
  - device: /dev/sdb
    type: 'sat'
  - device: /dev/nvme0
    type: 'nvme'

Then update your cron line to pass the config:

*/15 * * * * /opt/scrutiny/bin/scrutiny-collector-metrics run --api-endpoint "http://<LXC_IP>:8080" --config /opt/scrutiny/config/collector.yaml >/dev/null 2>&1

Find your devices with smartctl --scan on the Proxmox host. This is one of the most common issues people hit when first configuring Scrutiny SMART monitoring on Proxmox with multiple drive types.

NVMe Drive Shows No Temperature or Wear Data

NVMe support in Scrutiny SMART monitoring on Proxmox depends entirely on the smartmontools version installed on the host.

NVMe reports attributes in a different schema than SATA. Make sure your smartmontools version is 7.0 or newer — older versions have poor NVMe support. Check with smartctl --version.

The Collector Fails with “Connection refused”

This usually means the LXC firewall is blocking the connection to port 8080. When Scrutiny SMART monitoring on Proxmox is set up correctly, the collector on the host should reach the Hub LXC without issues.

Your LXC firewall or the Proxmox firewall might be blocking port 8080. From the Proxmox host, try:

curl -v http://<LXC_IP>:8080

If it times out, check firewall rules on both sides.

Dashboard Is Empty After Collector Runs Successfully

This is the #1 pain point with Scrutiny SMART monitoring on Proxmox. The most common cause is a version mismatch between the web container and the collector binary. Check both:

# On the LXC — check web version in logs
docker compose logs scrutiny-web | grep "linux\|dev-"

# On the Proxmox host — check collector version
/opt/scrutiny/bin/scrutiny-collector-metrics --version

Both must show the same version, e.g. 0.8.6. If they differ, downgrade the collector:

wget -O /opt/scrutiny/bin/scrutiny-collector-metrics \
  https://github.com/AnalogJ/scrutiny/releases/download/v0.8.6/scrutiny-collector-metrics-linux-amd64
chmod +x /opt/scrutiny/bin/scrutiny-collector-metrics

And update the web image in docker-compose.yml to match:

# In /opt/scrutiny on the LXC
docker compose down
sed -i 's|scrutiny:.*-web|scrutiny:v0.8.6-web|' docker-compose.yml
rm -f ./config/scrutiny.db && rm -rf ./influxdb
docker compose up -d

Docker Compose Can’t Pull the Image

Occasionally ghcr.io rate-limits anonymous pulls. Either wait and retry, or check the full tag list on the Scrutiny GitHub Container Registry.

What About My OMV and Home Assistant Hosts?

One of the best features of Scrutiny SMART monitoring on Proxmox is that the same Hub can serve multiple hosts. If, like me, you have OMV on an N100 and Home Assistant OS on another N100, you can point their collectors at the same Scrutiny Hub — that’s the whole beauty of hub-spoke. On each host:

On OpenMediaVault: install the collector binary the same way as on Proxmox (OMV is Debian underneath — identical steps). One important difference: OMV does not have root in PATH by default, so you must create collector.yaml with the explicit smartctl path. Use tee instead of cat > since redirection doesn’t work with sudo on OMV:

sudo tee /opt/scrutiny/config/collector.yaml << 'EOF'
version: 1
commands:
  metrics_smartctl_bin: /usr/sbin/smartctl
host:
  id: "omv"
EOF

On HAOS: this one is trickier because HAOS is not a normal Linux distro — you would need to run the collector as an addon or inside a privileged Docker container. For most people, running the N100 HAOS disks’ monitoring from within the HAOS OS itself is simpler, or just skipping it since HAOS typically runs on a single SSD.

Each collector should use a unique host.id in its collector.yaml so Scrutiny can tell the drives apart on the dashboard. This makes Scrutiny SMART monitoring on Proxmox scale cleanly across your entire homelab — one Hub, multiple spokes, all drives visible in a single dashboard.

Wrapping Up

You now have a proper Scrutiny SMART monitoring on Proxmox setup with:

A clean, unprivileged LXC running the Web UI and InfluxDB.
A native collector on the host with full access to SMART data.
Historical trends stored in InfluxDB.
Telegram alerts the moment something starts degrading.

Scrutiny SMART monitoring on Proxmox is the kind of setup that quietly saves your data one day when you least expect it. 💾 Given how cheap the compute is (literally <1% CPU), there’s basically no reason not to run it.

Drop a comment if you hit any issues — happy monitoring! 🛠️

Useful official documentation: