Spin_Retry_Count non-zero: the spindle motor is failing to spin up

Spin_Retry_Count (SMART attribute ID 10) counts how many times a hard drive’s spindle motor failed to reach operating RPM on the first attempt and retried. A healthy HDD spins up cleanly every time. Any non-zero value means the motor may not spin up on the next power cycle.

This attribute is HDD-only. SSDs have no spindle motor and do not report ID 10. If you see this attribute on an SSD, it is either a synthetic placeholder or a vendor repurposing of the ID for unrelated data.

The single most important diagnostic step is scope: does only one drive show retries, or do multiple drives in the same chassis show them simultaneously? One drive retrying points to that drive’s spindle motor failing. Multiple drives retrying at the same time points to a power-delivery problem: the 12V rail sagging during spin-up, a PSU that cannot supply enough inrush current, or staggered spin-up that is misconfigured or unsupported on the controller. These are fundamentally different problems with different fixes.

What this means

The spindle motor must accelerate the platters from rest to their rated RPM (5400, 7200, 10000, or 15000). This requires significant torque and draws a large inrush current, far more than steady-state operation. When the motor fails to reach target speed on the first attempt, the firmware aborts and retries. Each retry is counted in attribute ID 10.

The attribute is classified as Pre-fail, meaning it can trigger the overall SMART health assessment to change from PASSED to FAILED. The drive firmware compares the normalized VALUE column against a vendor-defined THRESH column. When VALUE drops below THRESH, smartctl reports “FAILING_NOW” in the WHEN_FAILED column. The exact THRESH varies by vendor and model; always read it from the drive rather than assuming a universal value.

On drives that expose a raw counter, the raw value is a cumulative count of spin retries and 0 has historically meant no observed retry. Implementations differ: Seagate’s 2011 SATA SMART specification says ID 10 has “No raw values” and normalizes it as 100 - average number of retries in the last eight spin-ups. Any non-zero raw value is abnormal on an enterprise drive in production. Consumer drives may occasionally show 1 or 2 from power glitches, but even those warrant investigation.

One important vendor quirk: some Seagate models report a raw value of 0 even when the normalized VALUE has dropped below THRESH, causing smartctl to display “FAILING_NOW” while the raw value reads 0. This is a firmware-level reporting inconsistency. On these drives, the normalized VALUE column and the WHEN_FAILED column are more reliable than the raw value. If you monitor only the raw value for ID 10, you may miss a drive whose firmware has crossed its threshold. Do not assume a firmware generation fixed this; check the actual raw value and normalized state for each model.

Common causes

Quick checks

# Check Spin_Retry_Count raw value and normalized VALUE/THRESH
smartctl -A /dev/sdX | grep -i "Spin_Retry"

# Check overall SMART health assessment
smartctl -H /dev/sdX

# Check Spin_Up_Time for corroborating motor degradation
smartctl -A /dev/sdX | grep -i "Spin_Up_Time"

# Check power cycle count for context on how many spin-ups the drive has attempted
smartctl -A /dev/sdX | grep -i "Power_Cycle"

# Check power-off retract count for unsafe shutdown context
smartctl -A /dev/sdX | grep -iE "Power.Off_Retract|Unexpect_Power"

# Check the full attribute table including WHEN_FAILED column
smartctl -a /dev/sdX | grep -A1 "Spin_Retry"

# Check whether multiple drives show spin retries (run across all drives)
for dev in /dev/sd[a-z]; do [ -b "$dev" ] && echo "$dev:" && smartctl -A "$dev" 2>/dev/null | grep -i "Spin_Retry"; done

# Check kernel logs for spin-up related errors or power events
dmesg | grep -iE "spin|power|reset|I/O error" | tail -20

How to diagnose it

The diagnostic flow hinges on one question: how many drives are affected?

flowchart TD
    A["Spin_Retry_Count ID 10 non-zero"] --> B{"One drive or multiple drives?"}
    B -->|"One drive"| C["Check Spin_Up_Time and Power_Cycle_Count"]
    B -->|"Multiple drives at once"| D["Power supply or 12V rail problem"]
    C --> E{"Normalized VALUE below THRESH?"}
    E -->|"Yes: FAILING_NOW"| F["Imminent motor failure. Replace before next power cycle."]
    E -->|"No: still above threshold"| G["Motor degrading. Plan replacement urgently."]
    D --> H["Check PSU capacity and staggered spin-up config"]
    H --> I{"Staggered spin-up enabled?"}
    I -->|"No"| J["Enable it or reduce drives per power rail"]
    I -->|"Yes"| K["PSU or UPS degradation. Check voltage rails."]

1. Determine scope. Query Spin_Retry_Count on every drive in the chassis. If only one drive is non-zero, proceed with single-drive diagnosis. If two or more drives are non-zero, especially if they share a power rail or enclosure, the problem is almost certainly power delivery, not individual drive motors.

2. For a single drive, check the normalized VALUE vs THRESH. If VALUE has dropped below THRESH and WHEN_FAILED shows “FAILING_NOW”, the drive firmware is asserting that the motor is failing. Treat this as urgent: the drive may not spin up after the next power cycle. If VALUE is still above THRESH but the raw value is non-zero, the motor is degraded but has not yet crossed the vendor failure threshold. Plan replacement, but do not power-cycle the drive unless you are prepared for it not to come back.

3. Cross-reference Spin_Up_Time (ID 3). If spin-up time is also increasing or elevated above baseline, the spindle bearing is degrading. Both signals together confirm mechanical motor system failure.

4. Check Power_Cycle_Count (ID 12). A drive with tens of thousands of power cycles and a single spin retry is in a different risk category than a drive with 5 power cycles and 3 retries. High cycle count plus retries means accumulated motor wear. Low cycle count plus retries points to either a manufacturing defect or an environmental cause such as cold or under-power.

5. For multiple drives, check the power infrastructure. Verify PSU health and capacity. Check whether staggered spin-up is enabled in the controller BIOS. Staggered spin-up support varies by controller, backplane, drive feature support, and firmware. Some SAS controllers exercise SAS spin-up control but do not support SATA PUIS/pin-11 staggered start; check the exact controller/drive combination rather than assuming a controller-family behavior.

6. Check UPS health. If the retries appeared after a power event, the UPS may have failed to provide clean power during the transition. Battery degradation in a UPS can cause voltage droop under load.

Metrics and signals to monitor

Fixes

Single drive: plan replacement before the next power cycle

A drive with spin retries has a motor that may not start on the next power-up. Do not power-cycle it as a diagnostic step. Instead:

1. Back up or migrate data from the drive while it is still spinning. The drive is currently operational, so take advantage of that.
2. Schedule replacement. If the drive is in a RAID array, initiate a controlled hot-spare rebuild rather than waiting for an uncontrolled failure.
3. After replacement, check the replacement drive’s SMART baseline to confirm the new drive has zero spin retries from the factory.

Multiple drives: fix the power infrastructure

If multiple drives show spin retries, the drives are not the problem.

1. Verify staggered spin-up is enabled. Check the HBA or RAID controller BIOS. If the controller does not support staggered spin-up for SATA drives, reduce the number of drives per power rail so the aggregate inrush current stays within the PSU capacity.
2. Check PSU capacity and health. Use IPMI, BMC, or a hardware diagnostic tool to read the 12V rail voltage. Sustained droop below specification during spin-up confirms a capacity or degradation problem.
3. Check UPS health. If the event followed a power restoration, the UPS battery may be degraded. Load-test the UPS and replace batteries if voltage droops under load.
4. Understand that the spin retry count is cumulative. The raw value does not reset when you fix the power problem. The existing non-zero count remains on affected drives as a historical record. The count should stop increasing once the power issue is resolved. Use rate-of-change monitoring to confirm the fix worked.

Cold environment: may be transient

A single spin retry on a drive operating below approximately 10 C may be caused by lubricant viscosity increasing at low temperature. If the retry does not recur after the drive warms to normal operating temperature, and the count does not increase on subsequent power cycles, it is likely benign. Repeated cold-start retries across multiple power cycles indicate the lubricant is degrading, which will eventually lead to bearing failure.

USB-attached drives: provide dedicated power

Bus-powered USB drives, especially those using Y-cables or connected through unpowered hubs, may show spin retries because the USB port cannot deliver sufficient inrush current. Provide a dedicated power supply to the enclosure or connect the drive directly to a powered USB port.

Prevention

• Enable staggered spin-up in dense enclosures. Without it, every drive draws peak inrush current simultaneously after a power restoration, stressing the PSU beyond its rated surge capacity.
• Monitor Spin_Retry_Count across the fleet. Alert on any non-zero value. For single-drive alerts, the response is replacement planning. For multi-drive alerts, the response is power infrastructure investigation.
• Capture a SMART baseline at deployment. Record the initial Spin_Retry_Count value when a drive is first installed. A drive that ships with zero should remain at zero. A drive that ships with a small non-zero count from factory burn-in testing should be noted as a baseline so future monitoring distinguishes historical values from new growth.
• Track the rate of change, not just the absolute value. A drive with a count of 1 that has been stable for two years is in a different risk category than a drive whose count went from 0 to 1 in the last week.
• Do not power-cycle a suspect drive unless prepared for failure. If a drive has spin retries and you power it down, it may not spin back up. This is the core operational risk: the failure mode is invisible while the drive is running and may become permanent on the next spin-up attempt.

How Netdata helps

• Per-second SMART attribute collection detects non-zero Spin_Retry_Count as soon as it appears, not at the next polling interval.
• Cross-drive correlation makes single-drive vs multi-drive disambiguation immediate. When multiple drives in the same host show Spin_Retry_Count incrementing simultaneously, the dashboard surfaces the pattern without manual iteration.
• Rate-of-change tracking distinguishes a stable historical count from active growth. Netdata’s anomaly detection flags the moment a previously stable attribute starts changing.
• Correlation with Spin_Up_Time, Power_Cycle_Count, and drive temperature provides the corroborating context to determine whether the cause is mechanical wear, power infrastructure, or environmental temperature, in the same time-aligned view.
• Host-level I/O metrics integration lets you correlate spin retry events with application-level latency spikes and kernel I/O errors, confirming whether the motor problem is already impacting production workloads.

Related guides

• Reading the ATA error log: UNC, ICRC, ABRT, CCTO, IDNF, AMNF
• Command_Timeout climbing: the drive is taking too long to respond
• Current_Pending_Sector non-zero: unreadable sectors and I/O latency spikes
• Data Units Written vs rated TBW: computing SSD endurance runway
• Drive temperature too high: HDD, SATA SSD, and NVMe thresholds
• SMART says PASSED but the drive is failing: why the health check lies
• I/O errors in dmesg with clean SMART: the failure the drive can’t see
• How S.M.A.R.T. actually works: a mental model for operators
• smartctl disk monitoring checklist: the SMART signals every server needs
• SMART monitoring maturity model: from survival to expert
• NVMe Available Spare below threshold: the spare block pool is running out
• NVMe Critical Warning bits: decoding the health-log bitmask