Why Your Hard Drives Are Probably Failing Right Now Without You Knowing
Hard drives fail quietly. There is no warning light on your case, no pop-up from your operating system, and no obvious sign until the day you go looking for a file and find nothing. Self-hosted health monitoring changes that by giving you continuous visibility into drive status before a failure becomes a data loss event.
Understanding S.M.A.R.T. Data and Why It Matters
Every modern hard drive and solid-state drive ships with S.M.A.R.T. built in – Self-Monitoring, Analysis, and Reporting Technology. It is a firmware-level system that tracks dozens of internal metrics: reallocated sectors, spin-up time, uncorrectable errors, temperature, power cycle count, and more. Most people never look at this data. Most systems never surface it. That is the problem self-hosted monitoring solves.
The key S.M.A.R.T. attributes to watch are not all equal. Reallocated Sector Count is the most telling for spinning drives – it means the drive found a bad sector and moved data off it, which is a sign of physical degradation. For SSDs, wear leveling count and available reserved space tell you how much usable life the flash cells have left. A single reallocated sector is not necessarily an emergency, but a rising count over weeks signals a drive that is actively deteriorating.
Temperature is often underestimated as a health indicator. Drives running consistently above 45 degrees Celsius accumulate wear faster, and drives that experience sudden temperature spikes can suffer immediate physical damage. Monitoring temperature over time also reveals cooling problems in your enclosure before they affect multiple drives at once.
The tool of choice for reading S.M.A.R.T. data on Linux and most self-hosted systems is smartmontools. It installs as a package on Debian, Ubuntu, Fedora, and Arch-based systems. The core binary, smartctl, lets you query any connected drive directly. Running smartctl -a /dev/sda returns the full attribute table for the first drive, including raw values, normalized scores, and threshold values that mark the point at which a manufacturer considers the drive failed.
Setting Up Automated Monitoring with smartd and Alerting
Manual checks do not scale. If you are running a home server, NAS, or any self-hosted storage setup with more than two drives, you need a daemon running continuously in the background. smartd is the monitoring daemon that ships with smartmontools, and configuring it properly takes about twenty minutes.
The configuration file lives at /etc/smartd.conf. The default setup scans detected drives but does not alert on much. The practical starting configuration uses the DEVICESCAN directive combined with options for scheduled tests, error notification, and temperature thresholds. A useful baseline entry looks like this: DEVICESCAN -a -o on -S on -s (S/../.././02|L/../../6/03) -W 4,40,45 -m root -M exec /usr/share/smartmontools/smartd-runner. Breaking that down – -a enables all checks, -o on turns on automatic offline testing, -S on enables attribute autosave, -s sets short tests nightly and long tests weekly, and -W watches temperature with a warning at 40 degrees and a critical alert at 45.
For email alerts to work, your system needs a mail transfer agent configured. On minimal server installs, msmtp with a Gmail or SMTP relay account is the simplest path. Configure /etc/msmtprc with your credentials, set sendmail to point to msmtp, and smartd will email you the moment a drive fails a test, reports a new error, or crosses a temperature threshold. Test the setup by sending a manual smartd alert before you rely on it for real incidents.
A more visual approach uses Scrutiny, an open-source web dashboard built specifically for S.M.A.R.T. monitoring. Scrutiny runs as a Docker container with a small collector binary deployed on each host that has drives attached. The collector runs on a cron schedule, pulls S.M.A.R.T. data from every drive, and posts it to the Scrutiny API. The web interface then displays drive health history, attribute trends over time, and a severity-coded overview of your entire storage fleet. It is the closest thing to a proper observability dashboard for home lab storage.
To deploy Scrutiny with Docker Compose, the minimal configuration needs the container running in privileged mode or with /dev/disk passed through so it can access raw drive interfaces. The image is ghcr.io/analogj/scrutiny:master-omnibus for the all-in-one version that bundles both the web UI and collector. Expose port 8080, mount a volume for the SQLite database, and set the SCRUTINY_WEB and SCRUTINY_COLLECTOR environment variables to true. After the first collector run, every drive on the host appears in the dashboard with current health status and a breakdown of any failing or warning-level attributes. If you are already running self-hosted storage services like Nextcloud as a Google Drive alternative, Scrutiny slots naturally into the same server stack.
Running Scheduled Tests and Interpreting Results
S.M.A.R.T. offers two test types that matter in practice. Short tests take two minutes and check the electrical components and a sample of the disk surface – run these nightly. Long tests check the entire disk surface and take anywhere from one hour to eight hours depending on drive size – run these weekly during off-peak hours. A drive that passes short tests but fails a long test has localized surface problems that are not yet showing up in daily attribute polling. That distinction matters because it catches degradation earlier than attribute thresholds alone.
When Scrutiny or smartd flags a drive, the response depends on which attribute is failing. A drive showing Pending Sector Count above zero needs immediate attention – those are sectors with read errors that have not yet been reallocated, meaning data in those locations is at risk right now. A drive showing elevated reallocated sectors but a stable count can often serve safely for a short period, long enough to copy data off before replacement. The worst scenario is a drive that passes all S.M.A.R.T. checks and then fails anyway – which does happen, and is exactly why backups exist independently of monitoring.
