scrutiny: a S.M.A.R.T dashboard that remembers what your disks did last month

Why the smartd daemon was not enough

The README is unusually honest about the problem it exists to solve, and it names smartd specifically. smartd is a daemon that polls the Self-Monitoring, Analysis and Reporting Technology system built into ATA, IDE and SCSI drives, runs self-tests, and warns when values cross thresholds. For a single workstation that is probably more than enough.

For a rack full of drives it leaves four gaps, and the README lists all of them. There are more than a hundred S.M.A.R.T attributes and smartd does not distinguish the critical ones from the informational ones, so the output is a wall of numbers. smartd keeps no history, so a slowly degrading attribute looks identical to a stable one. Vendor thresholds are set by the manufacturer and are sometimes unset or so loose that they can only confirm a drive has already died. And the tool is command line only, which is awkward on a headless box.

Scrutiny's answer is not to replace any of that machinery. The feature list puts smartd integration at the top, phrased as no re-inventing the wheel, and describes the project as merging manufacturer provided S.M.A.R.T metrics with real world failure rates. It is a collector, a time series database and a web UI wrapped around output that smartctl already knows how to produce.

One container with everything, or four with a database

The quick start is a single container that bundles the collector, the API and the frontend, which is the right first step for a home server.

docker run -p 8080:8080 -p 8086:8086 --restart unless-stopped \
  -v `pwd`/scrutiny:/opt/scrutiny/config \
  -v `pwd`/influxdb2:/opt/scrutiny/influxdb \
  -v /run/udev:/run/udev:ro \
  --cap-add SYS_RAWIO \
  --device=/dev/sda \
  --device=/dev/sdb \
  --name scrutiny \
  ghcr.io/analogj/scrutiny:latest-omnibus

The flags are doing real work here and the README explains each one. `--cap-add SYS_RAWIO` is what lets smartctl read device SMART data, and NVMe drives need `--cap-add SYS_ADMIN` on top of it, which is issue 26. The `--device` entries are what make each disk visible inside the container. The `/run/udev` mount is read only and exists so the collector can resolve device metadata such as serial numbers and model names, without which the dashboard ends up with a wall of anonymous drives.

For anything larger the project splits into pieces. One collector runs per server and holds the smartctl binary plus a cron style scheduler, one web container serves the UI and API, and InfluxDB stores the history.

docker run -p 8086:8086 --restart unless-stopped \
  -v `pwd`/influxdb2:/var/lib/influxdb2 \
  --name scrutiny-influxdb \
  influxdb:2.8

The database is the reason to care about the hub and spoke layout. Without a time series store, historical trends are the feature you lose, and historical trends are the whole argument for using this instead of smartd.

Disk detection is smartctl --scan, which is where trouble starts

Scrutiny discovers drives by running `smartctl --scan`, so anything that scan can read, Scrutiny can read. That inheritance is the project's main strength and also the source of most of its troubleshooting documentation.

On plain disks and on RAID controllers that pass SMART data through, this works out of the box, and the README states that all RAID controllers supported by smartctl are automatically supported. The failure mode is controllers that swallow SMART data: scan then returns incomplete data, tracked as issue 45, and Scrutiny's answer is to override the detected device type in the configuration file, with `example.collector.yaml` shipped as the reference.

The documentation is candid that you may need to debug this on your own. `docs/TROUBLESHOOTING_DEVICE_COLLECTOR.md` exists for exactly that, and `docs/TROUBLESHOOTING_INFLUXDB.md` covers the database side. Neither is unusual for a project of this size, but it is worth knowing that drive detection is not a solved problem on every controller before you promise someone a dashboard.

What the Go codebase is actually built from

The tree is small and legible at the top level: `collector/`, `webapp/`, `docker/`, `docs/`, `rootfs/`, two example config files and a `Makefile`. The dependency list in `go.mod` tells you more about the design than any diagram would.

module github.com/analogj/scrutiny

go 1.25.0

require (
	github.com/analogj/go-util v0.0.0-20210417161720-39b497cca03b
	github.com/gin-gonic/gin v1.11.0
	github.com/glebarez/sqlite v1.11.0
	github.com/influxdata/influxdb-client-go/v2 v2.14.0
	github.com/nicholas-fedor/shoutrrr v0.16.3
)

Gin is the HTTP layer for the API, the InfluxDB client is the history store, and shoutrrr is a notification library that fans a webhook out to whatever chat or email service you name, which is what makes the alerting feature cheap to implement. SQLite appears too, which is the detail worth pausing on: InfluxDB holds the metric time series, while SQLite holds configuration and the state the web app needs for things like user accounts.

The Makefile shows the second half of the story, with `COLLECTOR_BINARY_NAME = scrutiny-collector-metrics` and `WEB_BINARY_NAME = scrutiny-web`, plus static build support through `CGO_ENABLED = 0` and netgo tags. Two named binaries means the collector can be deployed on a machine with no web surface at all, which is the shape a real server room wants.

Thresholds from failure data, and a dashboard filtered to criticals

The feature list is short and each item is a complaint about smartd answered once. Auto-detection of all connected hard drives, S.M.A.R.T metric tracking for historical trends, customized thresholds using real world failure rates, temperature tracking, an all-in-one Docker image, and configurable alerting via webhooks. Performance testing and tracking is listed as future work, which is worth knowing if you were hoping for throughput numbers alongside the health ones.

The threshold idea is the most interesting part and the least explained in the README. Vendor thresholds tell you a drive has crossed a line the manufacturer chose, often conservatively. Scrutiny substitutes rates derived from real world failure data, and the README links a `REFERENCES.md` at the repository root as the place to look for the backing material. Anyone deploying this to make replacement decisions should read that file and the attribute definitions before trusting a red cell.

The UI side filters rather than dumps. The dashboard is described as focused on critical metrics, and a release note from v0.9.3 shows the drive details table growing real functionality, with a fix that made every column sortable after only three of the eight had been working. Small, unglamorous fixes like that are usually a decent signal about how a project is maintained.

Release cadence, version pinning, and the Work-in-Progress note

The README opens with a note that Scrutiny is a Work-in-Progress and still has some rough edges. That is the maintainer's own framing and it is consistent with the version numbers: v0.9.4 shipped on 2026-09-13, v0.9.3 on 2026-08-08, and v0.9.2 on 2026-04-28. The last push to master was 2026-09-13, so this is a project with current work landing on it, not one collecting dust.

The release bodies are generated changelogs, so they read as commit history rather than curated notes. v0.9.4 is almost entirely dependency bumps, including js-yaml and fast-uri updates pushed by dependabot. v0.9.3 contains the two real fixes mentioned above. v0.9.2 is interesting to anyone who has hit the same problem: it fixed a fallback WWN mismatch during migration to UUID drive identifiers, which was causing ghost disks, and added extra debugging output for UUID generation.

That ghost disk bug is worth remembering while reading the documentation, because it explains why the project now keys drives on UUID rather than whatever serial string it used to read. Container tags get the same caution. The README marks using `latest` tags as dangerous because an image can change without warning, and recommends pinning a semver tag such as `v0.9.4-omnibus` or `v0.9-web`. Given a project that admits to rough edges, pinning is the cheaper habit.

Editorial conclusion

Scrutiny is at its best on a homelab or a small fleet of servers where nobody has ever wired up alerting, because it removes the three arguments people have with smartd out of the way in one move. It deliberately does not replace smartd: the collector shells out to smartctl, so anything smartctl cannot read, Scrutiny cannot show. Start with the omnibus image on a single machine with two or three drives, pin the version rather than tracking latest, and turn on webhooks once you trust the numbers on screen. If you need predictive failure modelling rather than history and thresholds, this is not that tool.

Frequently asked questions

Official sources

1. AnalogJ/scrutiny on GitHub
2. Issues
3. License: MIT
4. README
5. Releases