Scrutiny

Last reviewed Aug 26, 2026 · 828 words

Scrutiny will tell you a drive has "failed" that smartctl says has passed. That is not a bug. Scrutiny's default threshold judges attributes against Backblaze's published failure statistics rather than the manufacturer's pass/fail line, and a drive with a handful of reallocated sectors that the vendor calls fine is, statistically, a drive Backblaze would replace. Knowing which threshold you are looking at is the difference between a monitoring tool you trust and one you mute after a week.

What a SMART dashboard adds over smartctl

Every disk already exposes SMART counters, and smartctl -a /dev/sda prints them. What you do not get from that is history, and history is where failure hides: a reallocated sector count that has been 0 for two years and became 8 last Tuesday is a warning; a count that has sat at 8 since you bought the drive used is not. Scrutiny collects the counters on a schedule, stores them in InfluxDB, and draws each attribute over time with temperature alongside. It handles SATA, SAS and NVMe, shows every drive across every host on one page, and colour-codes each one. The whole thing uses a few hundred megabytes and the catalogue's 256 MB minimum is realistic for a single host.

The omnibus image is the right start

Scrutiny is a web service plus a collector. The web service owns the dashboard and the database; the collector runs smartctl and posts the results. For one machine, the omnibus image bundles web, collector and InfluxDB together:

services:
  scrutiny:
    image: ghcr.io/analogj/scrutiny:master-omnibus
    ports: ["8080:8080"]
    cap_add: [SYS_RAWIO]
    volumes:
      - /run/udev:/run/udev:ro
      - ./config:/opt/scrutiny/config
      - ./influxdb:/opt/scrutiny/influxdb
    devices:
      - /dev/sda
      - /dev/sdb
      - /dev/nvme0
    restart: unless-stopped

SYS_RAWIO and the device list are non-negotiable; without them the collector sees no drives and the dashboard is blank. NVMe drives are passed as the controller device (/dev/nvme0), not the namespace. Drives behind some RAID controllers need a collector.yaml entry telling smartctl the device type, the same -d flag you would use by hand. The collector inside the omnibus runs on a cron, every 15 minutes by default, which is far more often than SMART values change and is fine.

Multiple hosts means one web, many collectors

For a NAS, a Proxmox host and two mini PCs, run the master-web image once and the master-collector image on each machine with COLLECTOR_API_ENDPOINT pointing at the web URL. The collector is stateless and tiny. This is the "needs collector on each host" complaint, and it is a modest one; the alternative, one dashboard per host, is what people do with Netdata and it is worse. Scrutiny does only disks, so it belongs next to a general monitor rather than instead of one; the homelab monitoring post shows where a disk dashboard fits in a stack with Uptime Kuma and a metrics tool.

The one setting that decides whether you trust it

In scrutiny.yaml, metrics.status_threshold takes smart, scrutiny or both. smart fails a drive only when the manufacturer thresholds say so, which is late; drives frequently die with every attribute "passing". scrutiny fails a drive when any attribute crosses the Backblaze-derived line, which is early and produces the alarming red badges on perfectly serviceable old disks. both (the default) is the union. My setting is scrutiny with metrics.status_filter_attributes: critical, which limits the Backblaze judgement to the five or so attributes that actually correlate with failure (reallocated sectors, pending sectors, uncorrectable errors, command timeouts, and end-to-end errors) and stops a warm drive with a high seek error rate from crying wolf. Set it once, and a red drive on the dashboard means "order a replacement", which is the behaviour you wanted.

Alerts go to whatever you already use

Notifications use Shoutrrr URLs under notify.urls, so a ntfy topic, Gotify, Discord, Telegram, email or a plain webhook all work with a one-line entry, and the web UI has a test button. Scrutiny notifies on a status change, not every 15 minutes, so it stays quiet until it matters. Combine it with the 3-2-1 backup discipline, because a failure prediction buys you days of warning and days are only useful if there is a backup to fail over to.

What I'd do

Run the omnibus image on the machine with the most disks, pass every drive through, set status_threshold: scrutiny with the critical attribute filter, and point notifications at ntfy. Add a collector on each other host with disks worth caring about. Look at the dashboard once a month and at the notification the moment it arrives. A drive that turns red gets replaced within the week, not debated; the historical graphs are there to convince you, and after the first time they are right you will not need convincing again.