NVMe temperature threshold exceeded: critical warning bit 1, WCTEMP, and CCTEMP

Your monitoring fired on an NVMe drive: critical_warning is non-zero, and after decoding the bitmask you find bit 1 set (value 0x02). The drive is reporting that its composite temperature has crossed a vendor-defined over-temperature threshold. The question that matters is whether this is a transient self-protecting throttle under heavy load, or a sustained thermal condition that is getting worse.

Bit 1 can fire during a perfectly healthy backup job and clear itself minutes later. It can also be the first signal of a cooling failure that ends in controller shutdown. The difference is not in the bit itself but in the surrounding counters: how long the condition has persisted, and whether time above the critical threshold is accumulating.

This guide covers what bit 1 actually reports, where WCTEMP and CCTEMP live (not where most tools look), how to read the real thresholds, and a triage model for deciding between a ticket and a page.

What critical warning bit 1 actually means

The NVMe SMART / Health Information log (Log ID 0x02) carries a critical_warning byte. Each bit is an independent assertion from the controller. Bit 1 means the composite temperature is greater than or equal to an over-temperature threshold, or less than or equal to an under-temperature threshold. In practice you will almost always see the over-temperature case.

Two thresholds govern this:

• WCTEMP (Warning Composite Temperature Threshold). Crossing it sets the bit and typically starts active thermal throttling. The drive reduces its internal clock and NAND interface rates to shed heat. Performance degrades, but the drive is self-protecting.
• CCTEMP (Critical Composite Temperature Threshold). This is the emergency zone. Sustained operation at or above CCTEMP risks controller shutdown and accelerated NAND degradation.

A key nuance: many drives set bit 1 at WCTEMP, which can be well below CCTEMP. So a set bit does not tell you which threshold was crossed. You need the current composite temperature and the actual threshold values to know how much headroom you have.

Where WCTEMP and CCTEMP live (and why your tools miss them)

WCTEMP and CCTEMP are fields in the Identify Controller data structure, not in the SMART log. This is the single most common gap in NVMe thermal monitoring: tools poll the SMART log, see a temperature and a critical warning bit, but never expose the thresholds the drive is actually measured against. Without the thresholds, “temperature is 71 C” is uninterpretable.

Read them from Identify Controller:

# Read the drive's actual thermal thresholds (values in Kelvin)
nvme id-ctrl /dev/nvme0 | grep -i temp

Typical output:

wctemp    : 343
cctemp    : 349

Both values are in Kelvin. Subtract 273.15 for Celsius: 343 K is about 70 C, 349 K is about 76 C. Typical ranges: consumer drives often report WCTEMP around 70-80 C and CCTEMP around 85 C; enterprise drives often run higher, with CCTEMP in the 90-100 C range. There is no universal constant, so never hardcode thresholds in alerts. Read them per drive.

Two edge cases worth knowing:

• WCTEMP of 0 disables the warning path. If the drive reports WCTEMP as 0, the over-temperature threshold behavior falls back to implementation-specific defaults, and the Warning Composite Temperature Time counter stays at 0 no matter how hot the drive gets. Some drives ship this way. If warning_temp_time is always 0 on a hot drive, check WCTEMP before assuming the drive has never throttled.
• The threshold can be changed at runtime. Feature ID 0x04 (Temperature Threshold) is readable with nvme get-feature /dev/nvme0 -f 0x04. Treat the drive-reported WCTEMP/CCTEMP as the baseline unless your team deliberately changed them.

Reading the current state

# Current critical warning byte and composite temperature
nvme smart-log /dev/nvme0 | grep -E "critical_warning|temperature"

# Time spent above warning and critical thresholds (minutes)
nvme smart-log /dev/nvme0 | grep -iE "warning_temp_time|critical_comp_time"

# Throttle state history
nvme smart-log /dev/nvme0 | grep -i thm_temp

Notes on what you get back:

• critical_warning with bit 1 set shows as value 0x02 (or higher values if other bits are also set; decode the whole byte, do not just check non-zero).
• The SMART log temperature is reported in Kelvin in JSON output; nvme smart-log /dev/nvme0 | grep temperature prints the converted value in most builds. If the number looks like Fahrenheit or Kelvin, check your locale or use -o json and convert yourself.
• warning_temp_time and critical_comp_time are cumulative minutes over the drive’s life. A static non-zero value is history. A rising value is a live event.
• Some drives do not implement the time counters and always report 0.
• thm_temp1_trans_count and thm_temp2_trans_count count entries into light (TMT1) and heavy (TMT2) throttle states. Not all drives implement them. If they do, a rising count corroborates throttling even when the temperature sample you caught looks fine.
• Composite temperature is also exposed via hwmon at /sys/class/nvme/nvme0/hwmon*/temp1_input in millidegrees Celsius, which is useful for continuous per-second monitoring without polling SMART.

One more caveat from the spec: composite temperature is implementation-defined. It may be a weighted combination of controller and NAND die sensors and “may not represent the actual temperature of any physical point in the NVM subsystem.” Drives with additional sensors expose them via hwmon as temp2_input, temp3_input, and so on. The NAND die can be significantly hotter than the composite value suggests.

Transient vs sustained: the triage decision

This is the whole operational question for bit 1. The severity model:

• TICKET on bit 1 alone. Sustained heavy I/O (backups, batch processing, benchmarks) can legitimately push composite temperature past WCTEMP. The drive throttles, sheds heat, and the condition clears when load drops. This deserves investigation during working hours, not a 3 a.m. page.
• PAGE when bit 1 is sustained for more than 5 minutes AND critical_comp_time is actively increasing. That combination means the thermal condition is not self-resolving and the drive is accumulating time above the critical threshold. This is a real thermal emergency: cooling failure, blocked airflow, or a workload the chassis cannot sustain.

flowchart TD
  A[critical_warning bit 1 set] --> B{Current temp vs WCTEMP and CCTEMP}
  B -->|below WCTEMP now| C[Check warning_temp_time rate and workload history]
  B -->|above WCTEMP, below CCTEMP| D{Bit sustained over 5 min?}
  B -->|at or above CCTEMP| E[PAGE: reduce load and check cooling now]
  D -->|no| F[TICKET: likely transient throttle under load]
  D -->|yes| G{critical_comp_time rising?}
  G -->|no| F
  G -->|yes| E
  C -->|past events only| H[Baseline: record thresholds, watch trend]

Working through it in practice:

1. Confirm which threshold is involved. Compare the current composite temperature against the WCTEMP and CCTEMP you read from nvme id-ctrl. If the drive is at 71 C against a WCTEMP of 70 C and a CCTEMP of 85 C, you are in the warning zone with real headroom left.
2. Check persistence. Bit 1 alone has no duration semantics. Sample temperature and the bit over a few minutes. A bit that clears as soon as the backup finishes is transient by definition.
3. Check the time counters’ rate of change. warning_temp_time rising means active time above WCTEMP. critical_comp_time rising is the escalation trigger: the drive is spending time above the critical threshold right now. A one-time historical bump in either counter with a flat current rate is a past event, not a live one.
4. Correlate with workload. Was there a backup, a RAID resync, a benchmark, a compaction storm? Transient trips under known heavy sequential write load are expected behavior, especially on M.2 drives without heatsinks.
5. Correlate with performance. Throttling shows up as gradually declining throughput and rising latency with zero errors. If performance recovered when load dropped, the thermal event explains it. If performance did not recover, you have a different problem; see nvme nvme0: I/O timeout, Resetting controller and NVMe controller reset loop.

Common causes

On the last row: there are widespread community reports of certain consumer drives, particularly Samsung 960/980/990 series, setting bit 1 with composite temperature well below WCTEMP. The self-assessment still reports PASSED and the temperature counters do not corroborate the event. If your drive shows bit 1 with a temperature 15 C below WCTEMP and flat time counters, treat it as a suspected firmware quirk, record it, and check for a firmware update. Do not ignore the bit entirely; verify the temperature independently each time.

Signals to monitor

A note on polling resolution: SMART counters are updated by the controller on its own schedule, and polling faster than every 30-60 seconds buys you nothing for the SMART-based fields. For fine-grained temperature, use the hwmon path (temp1_input), which is also what most per-second collectors read.

Reducing recurrence

• Fix airflow first. Most thermal bit-1 events on servers trace to blocked intake, failed fans, or M.2 drives in dead-air zones. On M.2, a heatsink is not optional for sustained workloads; without one, drives routinely hit warning territory under backup-class loads.
• Keep peak temperature 10 C or more below WCTEMP under your heaviest sustained workload. If a full backup brings you within 5 C of WCTEMP, the thermal solution is undersized.
• Smooth the workload where you can. Backups and batch jobs scheduled back-to-back keep the drive at thermal saturation. Staggering them costs nothing and often eliminates transient trips entirely.
• Baseline the thresholds per drive at provisioning. Record WCTEMP, CCTEMP, and whether the drive implements warning_temp_time, critical_comp_time, and TMT counters. Discovering WCTEMP is 0 during an incident is too late.
• Do not blanket-alert on critical_warning != 0. Bit 1 is transient-prone; bit 3 (read-only) is an unconditional page; bit 0 (spare below threshold) is a replacement ticket. Per-bit alerts with per-bit severity is the correct model. See NVMe monitoring checklist.

How Netdata helps

• Netdata decodes the critical_warning byte into per-bit dimensions on nvme.device_critical_warnings_state, so bit 1 (temp_threshold) alerts separately from bit 0, bit 2, and bit 3 instead of collapsing into one noisy “SMART critical” alarm.
• The nvme.device_composite_temperature chart gives you continuous temperature, so you can see whether the drive is near WCTEMP, drifting upward over days, or spiking only during known jobs.
• nvme.device_warning_composite_temperature_time and nvme.device_critical_composite_temperature_time are rendered as rates from the cumulative minute counters, which turns “did this happen” into “is this happening right now” - the exact distinction between TICKET and PAGE.
• Thermal management transition charts (nvme.device_thermal_mgmt_temp*_transitions_rate and *_time) confirm throttling independently of the temperature samples, catching brief events between SMART polls.
• Correlating temperature against throughput and latency on the same dashboard is what confirms the mechanism: temperature up, throughput down, zero errors is throttling; temperature normal with the same performance shape is a different failure pattern.

Related guides

• NVMe monitoring checklist: the signals every production SSD needs
• How NVMe actually works in production: a mental model for operators
• NVMe monitoring maturity model: from survival to expert
• nvme nvme0: I/O timeout, Resetting controller: what an NVMe controller reset means
• NVMe controller reset loop: repeated resets from a firmware hang
• NVMe controller state not live: reading resetting, deleting, and dead from sysfs
• blk_update_request: I/O error, dev nvme0n1: reading NVMe I/O errors in the kernel log
• NVMe device disappeared: nvme0: Removing and a drive that fell off the PCIe bus