Warning and Critical Composite Temperature Time: past overheating that already did damage

Two fields in the NVMe SMART/Health Information Log (Log Page 02h) record cumulative thermal exposure that a point-in-time temperature reading cannot show: Warning Composite Temperature Time and Critical Composite Temperature Time. They count the minutes the drive has spent above vendor-defined warning and critical temperature thresholds over its entire lifetime.

A non-zero value means the controller firmware accumulated a count. Even if Composite Temperature currently reads 40 degrees Celsius, these fields reveal thermal events that happened between polls, hours, days, or months ago. Thermal damage to NAND is cumulative and irreversible: sustained high temperature accelerates cell wear and degrades data retention. A drive that spent 200 minutes above its critical threshold may have aged more in those minutes than in months of normal operation. The question is not whether you can undo it (you cannot) but whether you can detect it and account for it in replacement planning.

What it is and why it matters

The fields live in the NVMe SMART/Health Information Log (Log Page 02h), the same log that reports Composite Temperature, Available Spare, Percentage Used, and the Critical Warning byte. The NVMe specification defines them as 32-bit unsigned integers tracking cumulative minutes:

• Warning Composite Temperature Time: minutes the controller was operational while Composite Temperature was at or above the Warning Composite Temperature Threshold (WCTEMP) and below the Critical Composite Temperature Threshold (CCTEMP).
• Critical Composite Temperature Time: minutes the controller was operational while Composite Temperature was at or above CCTEMP.

Both thresholds are vendor-defined and stored in the Identify Controller data structure. Typical values are 70 to 80 degrees Celsius for WCTEMP and 80 to 85 degrees Celsius for CCTEMP, but they vary by model.

These fields exist because polling is blind to events between samples. If you collect SMART data every 5 minutes and every sample shows 42 degrees Celsius, a 10-minute spike to 85 degrees between samples is invisible. The composite temperature time counters accumulate every minute the drive spends above threshold, regardless of collection interval.

How it works

Firmware continuously compares Composite Temperature against WCTEMP and CCTEMP. For each minute at or above WCTEMP but below CCTEMP, the Warning Comp. Temperature Time counter increments. For each minute at or above CCTEMP, the Critical Comp. Temperature Time counter increments.

flowchart TD
    A[Composite Temperature] --> B{Above CCTEMP?}
    B -->|Yes| C[Critical Comp. Temp Time
increments per minute]
    B -->|No| D{Above WCTEMP?}
    D -->|Yes| E[Warning Comp. Temp Time
increments per minute]
    D -->|No| F[Normal range
no counters increment]
    E --> G[Counters persist across
power cycles, never decrease]
    C --> G

Key properties:

• Cumulative across drive lifetime. Power cycling does not reset them. A drive that overheated in a test bench before deployment carries that exposure into production.
• Monotonically increasing. They never decrease. No mechanism clears them short of a firmware-level controller reset that would also reset all SMART data.
• 32-bit unsigned integers. The specification defines a maximum representable value of 4,294,967,295 minutes; it does not state wrap behavior for these two fields.
• Separate from Critical Warning bit 1. The bit reflects current thermal state. The time fields reflect historical cumulative exposure. A drive can have bit 1 clear while the time fields show hundreds of accumulated minutes above threshold.

To read the values:

# Check composite temperature time and related health fields
smartctl -a /dev/nvme0n1 | grep -iE "Comp.*Temperature Time|Composite Temperature|Critical Warning|Available Spare|Percentage Used"

To check the thresholds the drive is comparing against:

# WCTEMP and CCTEMP from Identify Controller data (0 means unset)
nvme id-ctrl /dev/nvme0n1 | grep -iE "WCTEMP|CCTEMP"

The WCTEMP=0 gotcha

If the manufacturer did not set WCTEMP or CCTEMP (stored as zero in the Identify Controller data structure), the corresponding time field is always zero regardless of actual temperature. This is specified NVMe behavior, not a bug. Consumer NVMe drives, especially budget models, may leave these thresholds unset. On those drives, the composite temperature time fields will always read zero even if the drive has been thermally abused.

Enterprise NVMe drives almost always set both thresholds. If you see zeros on every drive in a mixed fleet, verify the thresholds before concluding the drives have never overheaten.

Tool discrepancy note

The nvme-cli tool can also read these fields via nvme smart-log, but some kernel and driver versions have produced discrepancies where nvme smart-log reports zeros while smartctl shows non-zero values on the same drive. If results disagree, prefer smartctl output and verify that kernel and driver versions are current.

Where it shows up in production

Datacenter cooling failures

When a CRAC unit fails or hot aisle containment is breached, an entire row of drives may spike above WCTEMP for tens of minutes. Current temperature returns to normal once cooling is restored, but the counters now hold a permanent record. Weeks later, an operator auditing SMART data discovers non-zero values and can correlate them with the known cooling incident timeline.

M.2 NVMe drives without heatsinks

A drive running sustained write workloads without adequate heatsinking can exceed WCTEMP within minutes. Thermal throttling reduces performance but does not stop the counter from accumulating. The drive may throttle, cool slightly, resume full speed, heat up again, and cycle repeatedly. Each minute above threshold adds to the cumulative count.

Dense GPU-adjacent configurations

Drives positioned near GPUs or other heat-generating components experience elevated baseline temperatures. A drive whose idle temperature is 55 degrees Celsius has only 15 degrees of headroom before hitting a typical WCTEMP of 70 degrees. Under sustained load, it crosses the threshold quickly and may spend significant cumulative time in the warning zone.

Interpreting non-zero values

Warning Comp. Temperature Time above zero

The drive has spent time above its warning threshold. A few minutes during a brief workload spike is common and within the drive’s thermal design envelope. What matters is magnitude and whether it correlates with accelerated wear.

Cross-reference with Percentage Used. If the drive is consuming endurance faster than its write workload alone would explain, thermal stress may be a contributing factor. A drive with elevated Warning Comp. Temperature Time and a faster-than-expected Percentage Used climb warrants closer monitoring.

Critical Comp. Temperature Time above zero

The drive has spent time above its critical threshold. At or above CCTEMP, the drive is in a critical thermal condition and may throttle, shut down, or sustain permanent damage, so NAND data retention can degrade significantly. Sustained time at or above CCTEMP can cause irreversible damage.

Cross-reference with:

• Available Spare: if spare capacity is declining faster than expected, thermal damage may be consuming blocks.
• Media and Data Integrity Errors: any non-zero value here, especially if it appeared after a known thermal event, confirms physical NAND damage. Plan replacement.
• Critical Warning bit 2 (NVM subsystem reliability degraded): if set alongside elevated Critical Comp. Temperature Time, the firmware itself is reporting a reliability concern.

Verifying against false readings

Spurious temperature readings from kernel or driver bugs can cause the counters to increment incorrectly. If the reported thermal exposure seems implausible, check other drives in the same chassis. If all drives show elevated counts, the cause was likely environmental. If only one drive shows anomalous values while neighbors are zero, suspect either a real thermal issue specific to that drive’s position or a driver-level reporting anomaly.

The monitoring blind spot

The smartd daemon from smartmontools does not have built-in alerting for composite temperature time values. Its -W directive tracks current temperature changes but does not parse or threshold the cumulative time fields. A drive could accumulate hundreds of minutes above its critical threshold and smartd would never alert.

Detecting this signal requires custom smartctl output parsing or a collector that reads the NVMe SMART/Health Information Log directly. In the monitoring maturity model, tracking composite temperature time is a Level 3 (Mature) capability. See SMART monitoring maturity model for the full progression.

Signals to watch in production

How Netdata helps

• Correlating composite temperature time with Available Spare trends reveals whether past thermal events actually consumed spare blocks, distinguishing harmless brief spikes from damage-causing sustained overheating.
• Pairing cumulative counters with Percentage Used trends detects accelerated endurance consumption that may stem from thermal stress rather than write workload alone.
• Critical Warning byte and the temperature time fields together distinguish a current thermal event (bit 1 set) from a historical one (counters non-zero, bit clear), which changes urgency and response.
• Per-second collection granularity captures thermal excursions that fall between slower polling intervals, reducing the blind spots that make the cumulative counters necessary in the first place.

Related guides

• Drive temperature too high: HDD, SATA SSD, and NVMe thresholds
• NVMe Critical Warning bits: decoding the health-log bitmask
• NVMe Available Spare below threshold: the spare block pool is running out
• SMART says PASSED but the drive is failing: why the health check lies
• Data Units Written vs rated TBW: computing SSD endurance runway
• Command_Timeout climbing: the drive is taking too long to respond
• How S.M.A.R.T. actually works: a mental model for operators
• SMART monitoring maturity model: from survival to expert
• smartctl disk monitoring checklist: the SMART signals every server needs