Scrutiny
SMART data from every disk, tracked over time, scored against real failure rates
Scrutiny runs smartctl against your drives on a schedule, stores the attributes in InfluxDB, and shows a dashboard that flags failing disks using observed failure rates rather than the manufacturer thresholds smartd uses. It replaces reading `smartctl -a` by hand and hoping you notice a reallocated sector count creeping up.
Our verdict on Scrutiny#
The dashboard is genuinely good, and the cost structure is odd. You are running InfluxDB 2 and roughly 100 MB of RAM to track a few kilobytes of SMART attributes per drive per day. On a 12 bay NAS that is obviously worth it. On a two-disk mini PC, smartd with an email alert does 80% of the job for nothing, and you should be honest about which one you are. Device access is the real work: the container needs --cap-add SYS_RAWIO, --device for each drive, SYS_ADMIN on top for NVMe, and /run/udev mounted read-only for metadata. Current release is v0.9.3 from August 2026, still pre-1.0, and the README warns against latest- tags for exactly that reason. The collector defaults to one run a day at midnight, so a fresh install shows an empty dashboard until you trigger it by hand.
Who Scrutiny is for#
Choose it if
- Anyone running four or more disks who wants trend lines on reallocated sectors, not a one-off reading
- Homelabbers with a mix of drive ages who want early warning before a resilver turns into data loss
- People who found smartd's stock thresholds useless because they almost never trip before failure
- Multi-machine setups, where hub and spoke mode puts one collector per host and one dashboard
Look elsewhere if
- You have one or two disks and an MTA already configured; smartd covers that at zero cost
- You cannot grant the container raw device access, which rules out most managed or shared hosts
- Your disks sit behind a RAID controller that does not pass SMART data through to smartctl
What running it actually looks like#
The omnibus image bundles the web app, the collector and InfluxDB in one container: ports 8080 for the UI and 8086 for InfluxDB, volumes for /opt/scrutiny/config and /opt/scrutiny/influxdb, cap_add: SYS_RAWIO, a read-only /run/udev, and a --device entry for every drive you want scanned. NVMe drives additionally need SYS_ADMIN. Hub and spoke splits it into web, collector and an influxdb:2.8 container, which is the right shape when the disks live on several machines. On first start the web service runs InfluxDB onboarding automatically and writes the generated API token into scrutiny.yaml. The dashboard stays empty until the first collector run, so trigger it manually with docker exec scrutiny /opt/scrutiny/bin/scrutiny-collector-metrics run.
Resource profile#
- Memory
- 100 MB idle, around 250 MB in ordinary use. The project documents about 100 MB at idle for the omnibus image, nearly all of it InfluxDB. It grows with series count and during InfluxDB compaction, not with the number of drives.
- CPU and acceleration
- Idle almost always. The collector wakes on a cron schedule (daily at midnight by default), runs smartctl per device, and exits; InfluxDB compaction is the other periodic cost.
- Storage growth
- SMART attributes are tiny, but InfluxDB is not. With the default daily collection the data stays in the low tens of MB per drive per year; frequent collection multiplies it fast because downsampling assumes one run a day.
- Operational load
- 3 of 5, Moderate. A time series database with an API token that Scrutiny writes into its own config file, plus a collector on a separate schedule. Restores need both directories together and in the right state, and a mismatched token stops the app dead with a panic rather than a warning.
Figures describe a small single-household install and are the working assumptions behind our stack planner. Your numbers will differ with library size, user count and hardware. See methodology.
Data and backup surface#
Two directories, and they must be backed up as a pair. /opt/scrutiny/config holds scrutiny.yaml, which contains the InfluxDB API token, and scrutiny.db, the SQLite file with device records and settings. /opt/scrutiny/influxdb holds the metric history in buckets named metrics, metrics_weekly, metrics_monthly and metrics_yearly. Restore one without the other and Scrutiny panics on start with an authorization error. Stop the container before copying, because InfluxDB does not appreciate a live file copy. SMART history is nice to have rather than critical; the config is the part you cannot recreate quickly.
Derived backup shape
SQLite backup. sqlite3 <db> ".backup out.db" while running, or stop the container and copy. A live cp of a WAL-mode SQLite file can restore corrupt.
Traps and surprises#
NVMe needs SYS_ADMIN, not just SYS_RAWIO
Every guide shows --cap-add SYS_RAWIO, which is enough for SATA and SAS. NVMe drives return nothing without --cap-add SYS_ADMIN as well, and the failure mode is a device that appears in the list with no attributes rather than an error. If a drive shows up empty, check the capability before you start suspecting the drive or the controller.
A frequent collector cron explodes the database
Downsampling assumes roughly one collection a day: about 7 daily, 3 weekly and 11 monthly points per attribute per device. Set COLLECTOR_CRON_SCHEDULE to every 15 minutes and the project's own math puts you at nearly 55,000 datapoints per device, which the browser then tries to chart. Keep the daily default unless you have a specific reason, and never poll SMART minute by minute.
Losing the InfluxDB volume bricks startup
The API token generated during first-run onboarding is stored in scrutiny.yaml. If the InfluxDB directory was not persisted, the new InfluxDB has no matching token and Scrutiny exits with panic: unauthorized, or with onboarding has already been completed. The documented fix is to delete the web.influxdb.token field from scrutiny.yaml and restart, which regenerates it but leaves you with no history.
Every disk needs an explicit --device entry
Scrutiny scans with smartctl --scan inside the container, which can only see devices you passed in. Add a drive to the machine and it stays invisible until you edit the compose file and recreate the container. USB enclosures and RAID virtual disks often need a device type override in collector.yaml because autodetection returns partial data, which looks like a healthy drive with missing attributes.
Third party images and floating tags
The LinuxServer.io image behaved differently, used /scrutiny instead of /opt/scrutiny, and needed SCRUTINY_WEB and SCRUTINY_COLLECTOR environment variables that break the official image. Old tutorials still mix them. The README also warns against latest-omnibus on a pre-1.0 project: pin a version such as v0.9.3-omnibus so an unattended pull cannot change your database layout overnight.
Specifications#
- Category
- Monitoring and observability
- Licence
- MIT (Permissive)
- Written in
- Go
- First release
- 2020
- Maturity
- Stable
- Datastore
- InfluxDB 2 for metrics plus SQLite for devices and settings
- Default ports
8080,8086- Ships as
- docker (omnibus), docker (hub and spoke), native binary
- arm64 builds
- Yes
- Identity
- Auth proxy only. There is no login at all on the web UI or the API, so anything resembling access control has to be an authenticating proxy in front of port 8080.
- Replaces
- CrystalDiskInfo, Hard Disk Sentinel, Synology Storage Manager, QNAP Storage and Snapshots
- Project site
- github.com/AnalogJ/scrutiny
- Source
- github.com/AnalogJ/scrutiny
- Documentation
- github.com/AnalogJ/scrutiny#getting-started
Alternatives to Scrutiny#
Everything else in monitoring and observability, closest in operational weight first.
| Tool | Ops load | Idle RAM | Licence |
|---|---|---|---|
| Prometheus | 3, Moderate | 150 MB | Apache-2.0 |
| Grafana | 2, Light | 150 MB | AGPL-3.0-only |
| Netdata | 2, Light | 150 MB | GPL-3.0-or-later (agent); dashboard UI under NCUL1 |
| Uptime Kuma | 2, Light | 120 MB | MIT |
| Beszel | 1, Set and forget | 40 MB | MIT |
| Dozzle | 1, Set and forget | 15 MB | MIT |
Where Scrutiny comes up elsewhere#
Head to head
Sources#
Facts on this page were checked against the project's own material. Where a number is our own estimate rather than a published figure, the text says so.
Published . Last reviewed . Found something out of date? Tell us and we will fix it and log the change.