$ guides / smartctl-disk-monitoring / smartctl-power-on-hours-fleet-age ▌

Operations Guides

Power_On_Hours and fleet age: the context every other attribute needs

Power_On_Hours (ATA attribute ID 9, or the NVMe SMART/Health “Power On Hours” field) does not tell you anything is wrong. It tells you how long the drive has been powered on. That is the only attribute that gives every other attribute its meaning.

Ten reallocated sectors on a drive with 100 power-on hours is a manufacturing defect. Ten reallocated sectors on a drive with 50,000 power-on hours is graceful aging. The raw count is identical; the operational response is completely different. Without the age axis, you cannot distinguish “the drive is burning out” from “the drive is wearing out.”

What it is and why it matters

Power_On_Hours is the cumulative count of hours the drive has been powered on since manufacture. It is a lifetime counter: it only increases (or should only increase), it never resets under normal operation, and it persists across power cycles.

The signal exists in two places depending on drive type:

Drive type	Source	How to read it
ATA / SATA (HDD and SSD)	SMART Attribute ID 9 (Power_On_Hours)	`smartctl -A /dev/sdX`
NVMe	SMART/Health Information Log (Log Page 02h), “Power On Hours” field	`smartctl -A /dev/nvme0n1`

The raw value is hours on the vast majority of modern drives. The ATA spec does not standardize the unit, so some vendors use minutes, half-minutes, or multi-field encodings. smartmontools handles the conversion through its vendor preset database, but operators who raw-parse attribute values without going through smartctl will get wrong numbers on those drives.

Power_On_Hours matters for three operational decisions:

Normalizing other SMART signals. Every other attribute’s severity depends on drive age. The same raw value means different things at different ages.
Warranty and lifecycle tracking. Enterprise drives are typically rated for 5 years of continuous operation (~43,800 hours). Consumer drives are often rated for 8 hours/day over 5 years (~14,600 hours). Power_On_Hours tells you actual operational exposure, which is different from calendar warranty age.
Fleet risk management. Drives above roughly 50,000 hours (~5.7 years) have significantly higher failure probability regardless of what SMART reports. This is a fleet-statistics observation, not a per-drive prediction, but at scale it dominates failure planning.

How it works

ATA: attribute ID 9 and vendor encoding

For ATA/SATA drives, Power_On_Hours is SMART attribute ID 9. smartctl reads it as part of the standard attribute table:

# Read Power_On_Hours for a SATA drive
smartctl -A /dev/sda | grep -i "Power_On_Hours"

The default display format for attribute 9 is raw24(raw8): smartctl prints the raw value as a 24-bit number plus three optional 8-bit values if those bytes are nonzero. For most drives, the 24-bit value is the hour count and the extra bytes are zero, so the output looks clean.

The normalized value (the VALUE/WORST/THRESH columns) comes from the drive firmware. smartctl does not compute it. For the raw value column, smartctl applies vendor-specific interpretation rules from its drive database (for example, converting minutes to hours on affected Maxtor drives).

NVMe: a clean field

NVMe drives report Power On Hours as a 128-bit field in the SMART/Health Information log (Log Page 02h). There is no vendor-unit ambiguity on NVMe: it is always hours, always in the same place in the log page.

# Read Power On Hours for an NVMe drive
smartctl -A /dev/nvme0n1 | grep "Power On Hours"

Vendor quirks that corrupt the reading

Several vendor-specific encoding problems can make Power_On_Hours report nonsense:

Problem	Drives affected	What you see	Fix
Minutes instead of hours	Older Maxtor, some Hitachi	Raw value is ~60x too large	smartctl drive database applies `-v 9,minutes`; if not in database, add it manually
Seconds instead of hours	Older Fujitsu	Raw value is ~3600x too large	smartctl applies `-v 9,seconds` via preset
Half-minutes instead of hours	Some Maxtor variants	Raw value is ~120x too large	smartctl applies `-v 9,halfminutes`
msec24hour32 encoding	Intel 520, 330, other SandForce SSDs	Values like “931146h+18m+05.460s”	smartctl database applies `-v 9,msec24hour32`
Intel 520/330 firmware offset bug	Intel 520 firmware 400i, Intel 330 firmware 300i	Power_On_Hours reports ~894,794 hours (~102 years)	smartmontools decodes the drive’s `msec24hour32` format but does not subtract Intel’s firmware offset. Subtract 894,794 in your tooling.
2-byte rollover	Older Maxtor (pre-July 2003), some Seagate Barracuda	Counter wraps at 65,535 hours (~7.5 years), resetting to small numbers	No fix. Detect by checking for impossible decreases.

For the vendor-encoding problems (minutes, seconds, half-minutes, msec24hour32), the smartctl drive database should handle the conversion automatically. Verify which preset is applied:

# Check which vendor presets smartctl applies for this drive
smartctl -P show /dev/sda

Presets do not override explicit -v or -F flags you pass on the command line. If your drive is not in the database, force the correct interpretation:

# Force minutes interpretation for a drive not in the database
smartctl -A -v 9,minutes /dev/sda

The Intel 520/330 firmware offset bug is the most disruptive of these. The drive reports a power-on hour count inflated by roughly 894,794 hours. A drive with 100 real hours shows ~894,894. If you run Intel 520 or 330 drives with the affected firmware versions, detect the condition (drive model plus firmware version) and subtract the offset in your own tooling.

The bathtub curve and fleet failure probability

Drive failure probability over time follows a rough bathtub shape: elevated failures in the first 1-2 years (infant mortality), a low steady-state period, then rising failures as drives age. The exact shape depends on model and workload, but the general pattern holds across fleets.

Backblaze’s published fleet data provides accessible large-scale reference points. At the end of 2024 it reported a lifetime AFR of 1.31% across 298,230 qualifying data drives, with failures concentrated more heavily in older cohorts. Its 2025 bathtub-curve analysis reported a peak quarterly AFR of 4.25% at 10 years, 3 months.

The practical operator takeaway: drives above ~50,000 hours (~5.7 years) have measurably higher failure probability regardless of what their SMART attributes say. This does not mean every old drive is about to die. It means that in a fleet of thousands of drives, the old cohort generates disproportionate failures, and age should weight your risk assessment of every other signal.

Here is how power-on hours reframe the meaning of another SMART signal:

flowchart TD
    A["SMART signal: e.g., 10 reallocated sectors"] --> B{"What is Power_On_Hours?"}
    B -->|"Low, under 1,000h"| C["Manufacturing defect
or early-life failure
High concern: replace"]
    B -->|"Mid, 1,000 to 30,000h"| D["Accelerated degradation
Unusual at this age
Investigate root cause"]
    B -->|"High, over 30,000h"| E["Expected wear
Normalize against age
Track rate of change"]

Where it shows up in production

Warranty and lifecycle tracking

Enterprise drives are typically rated for 5 years of continuous operation. That rating assumes ~43,800 power-on hours (24/7 for 5 years). Consumer drives are often rated for 8 hours/day over 5 years (~14,600 hours). Running consumer drives 24/7 exceeds their design assumptions even if the calendar warranty period is the same.

Power_On_Hours tells you operational wear independent of calendar deployment time. A drive that sat in a warehouse for 18 months before deployment has significant elapsed calendar warranty time but near-zero power-on hours. A drive deployed immediately and running 24/7 accumulates hours faster than a drive of the same deployment date in a standby-heavy workload.

Some enterprise warranties include a maximum power-on-hour or TBW condition (“whichever comes first”). In those cases, Power_On_Hours directly affects warranty status. Check the specific drive datasheet.

For fleet replacement planning, group drives by power-on-hour bands and project when each cohort crosses your retirement threshold:

Power-on hours	Approximate age	Operational posture
0 - 8,760	0 - 1 year	Infant mortality window. Watch for early failures.
8,760 - 26,280	1 - 3 years	Steady state. Lowest failure probability.
26,280 - 43,800	3 - 5 years	Approaching warranty expiration. Begin replacement planning.
43,800 - 50,000	5 - 5.7 years	Past warranty. Elevated failure risk. Prioritize for replacement.
> 50,000	> 5.7 years	Significantly higher failure probability. Plan active rotation.

These are rough bands, not hard thresholds. The actual inflection point depends on drive model, workload intensity, thermal history, and manufacturing batch.

Normalizing rate-of-change signals

The most important use of Power_On_Hours is not the absolute value. It is the denominator for rate-of-change calculations. A drive that gained 5 reallocated sectors in the last 100 power-on hours is in active failure. A drive that gained 5 reallocated sectors over 50,000 power-on hours is aging normally.

For monitoring systems that track SMART attribute deltas, always compute rates per power-on-hour, not per wall-clock hour. Wall-clock time includes periods where the drive was idle, in standby, or powered off. Power-on hours reflect actual operational exposure.

MTBF: what it is and what it is not

MTBF (Mean Time Between Failures) figures like “2 million hours” are fleet statistics, not per-drive predictions. A 2-million-hour MTBF does not mean any individual drive will last 2 million hours (~228 years). It means that in a fleet of 2 million drives, you expect roughly one failure per hour on average.

MTBF is derived from accelerated life testing and statistical modeling. It is useful for comparing the relative reliability of different drive models under similar workloads, but it tells you nothing about when your specific drive will fail. Do not use MTBF to compute expected service life for individual drives.

Common misuses

Alerting on power-on hours alone

Power_On_Hours should never trigger a page on its own. A high power-on hour count is not a failure. It is a risk factor that changes how you interpret other signals. Alerting on “power-on hours > X” will page you about every old drive in the fleet, including the ones that will run fine for years.

The correct approach is to use power-on hours as a filter or weight on other alerts. For example: “reallocated sector count increased AND power-on hours > 40,000” is more actionable than either condition alone.

Trusting the raw value without checking vendor encoding

On drives with minute, second, or multi-field encodings, raw-parsing attribute ID 9 as a simple integer produces absurd numbers. A Maxtor drive reporting 600,000 “hours” is actually reporting 600,000 minutes (~10,000 hours). Always go through smartctl’s vendor-aware parsing, and verify with -P show that the correct preset is applied for drives known to have non-standard encodings.

Ignoring the Intel 520/330 offset bug

If you run Intel 520 or 330 SSDs with affected firmware, every power-on-hour reading is inflated by ~894,794 hours. Monitoring systems that chart this value will show a flat line near 900,000 hours that barely changes, because the real accumulation is dwarfed by the offset. Detect this condition (drive model plus firmware version) and either subtract the offset or exclude these drives from power-on-hour-based logic.

Assuming the counter never rolls over

Older drives with 2-byte (16-bit) power-on-hour fields roll over at 65,535 hours. A drive that has been running for 8 years (~70,000 hours) may show a power-on-hour count of ~4,500 because it wrapped. A plain 32-bit hours field would require about 490,000 years to wrap, so practical rollover is primarily an old 16-bit or vendor-specific-encoding concern. Detect rollover by checking for impossible decreases: if power-on hours dropped between two consecutive reads without a drive replacement, you have either a rollover or a firmware bug.

Signals to watch in production

Signal	Why it matters	Warning sign
Power_On_Hours raw value	The age axis for every other signal	Impossible values (over 900,000h on non-buggy drives), sudden decreases, or values inconsistent with deployment date
Rate of change in Power_On_Hours	Confirms the counter is advancing normally	No increase between consecutive reads (counter stuck) or decrease (rollover or firmware bug)
Power_On_Hours vs. calendar deployment time	Detects standby-heavy workloads or previously used drives	Hours significantly higher than expected from deployment date (possible refurbished or mislabeled drive)
Drive model and firmware version	Identifies drives with known encoding bugs	Intel 520 with firmware 400i or Intel 330 with firmware 300i reporting ~894,794h offset
Fleet age distribution	Drives replacement planning and risk assessment	Large cohort crossing 40,000-50,000 hours simultaneously

How Netdata helps

Netdata collects Power_On_Hours alongside every other SMART attribute through its smartctl integration, giving the monitoring system the age axis it needs to interpret everything else correctly.

Per-attribute normalization by age. Netdata charts reallocated sector rate, pending sector count, and error log growth alongside power-on hours, making it obvious whether degradation is accelerating relative to age or tracking an expected wear curve.
Rate-of-change detection. Netdata’s anomaly detection flags when any SMART counter starts growing faster than its historical baseline. Combined with power-on hours as context, this distinguishes “old drive wearing out gradually” from “drive of any age entering active failure.”
Fleet-level visibility. Aggregating power-on hours across all drives in a host or cluster shows the age distribution of the fleet at a glance, surfacing cohorts approaching retirement thresholds.
Vendor-encoding transparency. Netdata relies on smartctl’s vendor-aware parsing, so power-on-hour values are already corrected for minute, second, and multi-field encodings on drives where the smartctl database applies a preset.
Counter integrity monitoring. Tracking power-on hours over time surfaces impossible decreases (rollover, firmware bugs, silent drive swaps) as anomalies that would otherwise go unnoticed.