$ guides / smartctl-disk-monitoring / smartctl-scheduling-self-tests ▌

Operations Guides

Scheduling SMART self-tests: short weekly, extended monthly

Drives do not run self-tests automatically. SMART firmware monitors passively, recording what it sees during normal I/O. If a sector is never read by production traffic, its degradation stays invisible until a backup job, a scrub, or a user request hits it. At that point you get an I/O error in production instead of a warning from the drive.

Self-tests are the active probing mechanism. The short test (1-2 minutes) exercises electrical and mechanical basics plus a small media sample. The extended test (hours, proportional to drive size) scans the entire surface and is the only routine mechanism that discovers latent bad sectors before production I/O reaches them. The conveyance test (~5 minutes, HDD only) checks for shipping damage and is typically run once at deployment, not on a schedule.

The standard practice: short test weekly, extended test monthly. The smartd daemon from smartmontools automates both via a single configuration directive.

What scheduled self-tests detect

Latent defects: The extended test reads every sector. Degrading sectors that pass normal I/O get surfaced as self-test read failures with the exact LBA.
Early warning: Self-test failures appear in smartctl -l selftest days or weeks before the drive’s overall health assessment flips to FAILED.
Corroboration for attribute changes: When Current Pending Sector (ID 197) or Offline Uncorrectable (ID 198) starts climbing, self-test results confirm whether those pending sectors are active defects or transient.

Without scheduled self-tests, you rely on production I/O to find bad sectors at the worst possible time.

Prerequisites

smartmontools installed and smartd enabled.
smartctl can query target drives: smartctl -i /dev/sdX returns device info.
For NVMe: smartd-scheduled self-tests require smartmontools 7.5 or later. Smartmontools 7.4 added manual smartctl -t short and -t long for NVMe, but smartd scheduling was not available until 7.5.

smartctl --version | head -1

Procedure

The -s directive

The smartd.conf -s directive accepts a regular expression with the format T/MM/DD/d/HH:

Component	Meaning	Range
T	Test type	S (Short), L (Long/Extended), C (Conveyance, ATA only), O (Offline Immediate, ATA only)
MM	Month	01-12
DD	Day of month	01-31
d	Day of week	1=Monday through 7=Sunday
HH	Hour	00-23

Each field after T is a regex matched against the current date and time. A dot (.) matches any single character. Day-of-week is a single digit (1-7), so use . (not ..) to match any day. Using .. in the d field will fail to match because it consumes two characters where only one exists, causing tests to silently never run.

When the regex matches during a smartd polling cycle, smartd starts that test type. smartd polls every 30 minutes by default, so tests start within 30 minutes of the scheduled hour, not at the exact minute.

flowchart TD
    A["smartd polling cycle (every 30 min)"] --> B{"Does -s regex match
current date/time?"}
    B -->|No| A
    B -->|Yes| C{"Is a self-test
already running?"}
    C -->|Yes| D["Skip - do not interrupt"]
    C -->|No| E{"Was a test started
this hour?"}
    E -->|Yes| D
    E -->|No| F["Start scheduled self-test"]
    F --> G["Test runs in background
alongside host I/O"]
    G --> H["Result written to
self-test log"]

Configuring short weekly and extended monthly

Edit /etc/smartd.conf. Add -s (...) to the existing DEVICESCAN line, preserving any existing directives such as -m root:

# /etc/smartd.conf
# Short test every Sunday 02:00-03:00
# Extended test on the 1st of each month at 03:00
DEVICESCAN -s (S/../../7/02|L/../01/./03)

Breaking this down:

S/../../7/02: Short test, any month, any day of month, day 7 (Sunday), hour 02.
L/../01/./03: Long test, any month, day 01, any day of week (single .), hour 03.
The pipe (|) combines both patterns so either match triggers the respective test.

For per-device configuration, comment out DEVICESCAN first. An active DEVICESCAN line causes smartd to ignore all subsequent device entries:

# Comment out DEVICESCAN when using per-device lines
#DEVICESCAN -m root
/dev/sda -s (S/../../7/02|L/../01/./03)
/dev/sdb -s (S/../../7/02|L/../01/./03)

Staggering tests across drives

If you have many drives, simultaneous extended tests can saturate I/O. Smartmontools 7.2 reportedly introduced a :NNN suffix to spread test start times across drives:

/dev/sda -s (S/../../7/02|L/../01/./03:003)
/dev/sdb -s (S/../../7/02|L/../01/./03:003)

The :003 suffix reportedly means stagger with 3-hour steps. smartd assigns each matching device a sequential slot: first drive at 03:00, second at 06:00, third at 09:00. Verify your version supports this before relying on it. If it does not, offset test hours per device manually:

/dev/sda -s (S/../../7/02|L/../01/./03)
/dev/sdb -s (S/../../7/02|L/../01/./04)

Applying the configuration

# Validate the schedule before restarting
# This prints the parsed schedule and exits without running tests
sudo smartd -q showtests

# Restart smartd to apply (service name varies by distribution)
systemctl restart smartd          # RHEL, Fedora, Arch
systemctl restart smartmontools   # Debian, Ubuntu

Alternative: cron-based scheduling

If smartd is impractical (for example, behind a RAID controller where device paths change), schedule tests via cron:

# /etc/cron.d/smart-tests
# Weekly short test on Sunday at 02:00
0 2 * * 0 root smartctl -t short /dev/sda
# Monthly extended test on the 1st at 03:00
0 3 1 * * root smartctl -t long /dev/sda

For drives behind a hardware RAID controller, use the appropriate passthrough device type:

# LSI/Broadcom MegaRAID passthrough
0 3 1 * * root smartctl -d megaraid,0 -t long /dev/sda

Verifying it works

Check if a test is currently running

# SATA/SAS self-test execution status
smartctl -c /dev/sdX | grep -A5 "Self-test"
# NVMe: check via the self-test log
smartctl -l selftest /dev/nvme0n1

Check self-test results

smartctl -l selftest /dev/sdX

A successful test shows “Completed without error.” A failing test shows the failure type (read failure, servo failure, electrical failure) and the LBA of the defect.

Confirm smartd loaded the configuration

systemctl status smartd
journalctl -u smartd --since "1 hour ago" | tail -20

If smartd did not start, check the journal for syntax errors in the -s regex.

Common pitfalls

Default configuration does not schedule tests. Most distributions ship /etc/smartd.conf with a bare DEVICESCAN line and no -s directive. No -s means no self-tests ever run.

NVMe scheduling requires smartmontools 7.5+. The -s directive is silently ignored for NVMe devices on earlier versions. smartctl -t short and -t long work on NVMe from 7.4 onward, but smartd scheduling was added in 7.5. Ubuntu 24.04 LTS shipped with smartmontools 7.4.

smartd does not interrupt running tests. If a test is in progress when the next scheduled time arrives, smartd skips it. An extended test on a large HDD can take 8+ hours and may overlap the next scheduled short test window. smartd also will not start a second test if one was already started in the same hour.

Polling interval affects timing. smartd checks the schedule at the end of each polling cycle, not at the exact scheduled minute. With the default 30-minute interval, a test scheduled for 02:00 may start between 02:00 and 02:30. If you set a custom interval longer than 60 minutes, tests may be delayed or skipped entirely.

Heavy I/O can abort extended tests. The drive prioritizes host commands over self-test operations. Under sustained heavy I/O, the drive may abort the test. If your self-test log shows repeated “Aborted by host” or “Interrupted” results, reschedule to a lower-traffic window.

Conveyance test is ATA-only. The C test type is only valid for ATA/SATA devices. NVMe and SCSI do not support it.

Automatic offline data collection is not a self-test. The -o on directive enables automatic offline data collection, which is passive firmware data gathering. It does not perform surface scanning and does not substitute for self-tests.

Device paths behind RAID controllers may change. Use persistent device names (/dev/disk/by-id/) or RAID controller passthrough identifiers for stability across reboots and controller rescans.

Signals to monitor

Signal	Why it matters	Warning sign
Self-test log (`smartctl -l selftest`)	Primary output of scheduled tests	Any result other than “Completed without error”
Current Pending Sector (ID 197)	Self-tests surface sectors that become pending	Non-zero or increasing after a scheduled test
Offline Uncorrectable (ID 198)	Extended tests may confirm pending sectors as permanently unreadable	Any increase from baseline
Reallocated Sector Count (ID 5)	Self-test reads may trigger reallocations	Any increase from baseline
NVMe Media and Data Integrity Errors	NVMe equivalent of uncorrectable errors	Any non-zero value
Self-test aborted count	Indicates tests are not completing due to I/O pressure	Repeated “Aborted by host” results across cycles

How Netdata helps

Netdata’s smartctl data collector ingests self-test results, so you can see when a scheduled test ran and what it found without running smartctl -l selftest on each host. When an extended test reports a read failure, Netdata correlates it with SMART attribute movement (Current Pending Sector, Offline Uncorrectable, Reallocated Sector Count) in the same window, confirming active media degradation rather than a transient event.

Netdata baselines cumulative counters at first observation and alerts on growth, so a self-test that triggers new reallocations produces an actionable alert rather than a static number that requires manual interpretation. If extended tests cause I/O contention, per-second disk latency metrics show the impact immediately, helping you tune scheduling windows.