NVMe Critical Warning 0x02 Temperature: What the smartd Alert Really Means

The short answer

Device: /dev/nvme0, Critical Warning (0x02): Temperature is one of the most alarming-looking lines a home server can email you, and one of the least dangerous. 0x02 is a single bit in a single byte. It means the drive’s composite temperature is currently outside its threshold band. Nothing more.

Three facts resolve almost every case:

1. It is a live state, not a latched fault. The NVMe specification defines bit 1 as “temperature is above an over temperature threshold or below an under temperature threshold” — present tense. A drive reporting 0x00 right now is not hot right now.
2. smartd remembers. The alert you are reading was generated by the smartd daemon, which keeps its own state and repeats the warning every 24 hours. A drive can be cool and still be emailed about.
3. The truth is in two cumulative counters. Warning Composite Temperature Time and Critical Composite Temperature Time count minutes spent above each threshold. They are the only evidence of an excursion you did not personally watch.

So the workflow is: read the current value, read the two counters, compare the two temperature sensors, then decide. Everything below is that workflow with real numbers attached.

1. Where the alert comes from

The message does not come from the drive. It comes from smartd, the monitoring daemon in the smartmontools package, which polls devices on a schedule and mails warnings through the exec hook configured in /etc/smartd.conf. The stock Debian and Proxmox configuration ships a single scan line:

DEVICESCAN -d removable -n standby -m root -M exec /usr/share/smartmontools/smartd-runner

The full alert that reaches an administrator’s inbox looks like this:

This message was generated by the smartd daemon running on:

host name: pve

The following warning/error was logged by the smartd daemon:

Device: /dev/nvme0, Critical Warning (0x02): Temperature

Device info: Samsung SSD 980 1TB, S/N:xxxx, FW:2B4QFXO7, 1.00 TB

For details see host's SYSLOG.

The original message about this issue was sent at Tue Sep 6 12:25:29 2022 CEST
Another message will be sent in 24 hours if the problem persists.

Two details in that text matter. The subject line reports the device path (/dev/nvme0), not a fault code. And the trailing line confirms the repeat behaviour: smartd will keep mailing until its remembered condition clears. That is why a one-off heat event from a failed air conditioner can generate weeks of mail after the room is cool again.

2. The Critical Warning bitmap

The Critical Warning field is byte 0 of the NVMe SMART/Health Information log (log identifier 02h). Each of the first five bits is an independent condition, and multiple bits can be set at the same time — 0x03 means spare and temperature together, because the values are OR-ed. The definitions below are identical across the Intel SSD 750 Series product specification, the Seagate Nytro 5000 product manual and the smartmontools source as explained by its maintainers on the project mailing list.

The relative severity is the point. 0x02 is the only bit in that table that a fan can fix. Every other set bit describes physical degradation or a failed protection mechanism, where the correct response is evacuation rather than cooling.

One trap: a value that sets bit 5, 6 or 7 makes smartctl print “unknown critical warning(s)”. The byte is then genuinely unreadable by the tool, not merely unusual — capture the raw log rather than trusting the summary line.

3. Two temperatures, two counters, and one threshold pair

NVMe health reporting separates now from how long. Confusing the two is what makes 0x02 feel like a mystery.

Both time counters are cumulative over the life of the drive and are stored in the SMART log at bytes 192 and 196. They never reset on their own. A drive that spent one bad night in a hot room carries that number forever, which is exactly what makes them useful — and exactly why they cannot tell you whether the problem is ongoing.

WCTEMP and CCTEMP are set by the vendor, not by the specification, so you must read them from your own drive. A Samsung SSD 980 1TB reports Warning Comp. Temp. Threshold: 82 Celsius and Critical Comp. Temp. Threshold: 85 Celsius. A 3 °C band between the two is normal, and it explains why Critical Composite Temperature Time is frequently zero while Warning Composite Temperature Time is in the hundreds: drives throttle long before they reach the critical threshold.

4. A clean capture from our own test unit

This is the internal drive of our Beelink EQi12 test unit, captured with smartctl 7.5 on 2026-07-11. The full text is published in our measurement data repository under storage/EQi12_InternalSSD_SMART_2026-07-11.txt.

Two honesty notes, because they are the difference between evidence and decoration. First, this archived capture does not contain WCTEMP or CCTEMP — our log line did not include the Identify Controller block, so we do not publish numbers we did not read. Second, the sustained 50 GiB transfer run performed minutes earlier recorded this explicitly:

Temperature/SMART detail: unavailable because Storage Reliability Counter access was denied; do not infer temperature.

That is the discipline this site runs on. A missing counter is reported as missing. On that run the same drive measured 623.29 MiB/s sustained write and 468.2 MiB/s full read, details of which are on the EQi12 SSD and USB port evidence page.

The Unsafe Shutdowns: 2 line is the one item we would act on. Two unannounced power losses in ten cycles on a host that was only being benchmarked points at cabling, a loose adapter or an abrupt OS shutdown — not at the drive.

5. Two documented 0x02 alerts, two completely different causes

Neither of these is ours. Both are publicly documented cases, and together they cover the overwhelming majority of real 0x02 reports.

Case A is the classic false alarm that was once true. The room overheated, the drive spent 748 minutes above its 82 °C warning threshold, and cooling was restored. The drive is fine: 0x00, 43 °C, zero media errors, zero critical temperature minutes. But smartd’s remembered state survives reboots, so the mail kept arriving daily. The fix is a daemon restart, not a new SSD.

Case B is the more dangerous one, because the drive genuinely reports 0x02 continuously. The tell is the sensor spread: 84 °C on sensor 1 against 19 °C on sensor 2 is not a thermal gradient, it is a broken reading. No 65 °C delta exists across a 22 mm-wide M.2 module. The resolution reported in the community is a firmware update from the vendor’s support tool.

The general rule falls straight out of Case B: compare the sensors before you buy a heatsink. A spread beyond roughly 10–15 °C on a client M.2 drive is a reporting fault, not a cooling fault.

6. The triage decision tree

Run these in order. Stop as soon as a branch resolves.

1. Read Critical Warning
   ├─ 0x04, 0x08 or 0x10 set  → STOP. Back up now. Replace the drive.
   ├─ 0x01 set                → Check Available Spare vs threshold. Plan replacement.
   └─ 0x02 only               → continue
2. Read current Temperature
   ├─ At/above WCTEMP right now → Real, active thermal problem. Go to step 5.
   └─ Below WCTEMP              → Not hot now. Continue.
3. Read Warning & Critical Composite Temperature Time
   ├─ Both 0                    → No excursion ever recorded.
   │                              → Suspect firmware or a transient read error. Check sensor spread (step 4).
   ├─ Warning > 0, Critical 0   → A past, non-critical excursion. Fix cooling, then clear daemon state.
   └─ Critical > 0              → The drive exceeded CCTEMP. Treat as real. Check media errors.
4. Compare Temperature Sensor 1 vs Sensor 2
   ├─ Spread > ~15 °C           → Reporting fault. Update firmware. Do not buy cooling.
   └─ Spread small              → The reading is trustworthy. Continue.
5. Read Media and Data Integrity Errors + Error Information Log Entries
   ├─ Both 0                    → Cooling problem only. No data lost yet.
   └─ Either > 0                → Thermal damage may have occurred. Back up and plan replacement.
6. Fix cause, then verify
   ├─ Restore airflow / move the drive out of a hot enclosure
   ├─ Restart smartd to clear remembered state
   └─ Re-read after one full workload cycle. Warning time must stop climbing.

Symptom-to-action, condensed:

7. Commands

Capture the full report. -x includes the NVMe log pages that -a may summarise:

sudo smartctl -x /dev/nvme0

The vendor-neutral equivalent, useful when smartctl is not installed:

sudo nvme smart-log /dev/nvme0

Extract only the fields this article depends on:

sudo smartctl -x /dev/nvme0 | grep -Ei \
  'Critical Warning|Temperature|Available Spare|Percentage Used|Media and Data|Error Information Log|Power On Hours|Unsafe Shutdowns'

Confirm thresholds for your specific drive — never assume another model’s numbers:

sudo smartctl -x /dev/nvme0 | grep -Ei 'Comp\. Temp\. Threshold'

Clear a latched smartd alert on Debian, Ubuntu or Proxmox:

sudo systemctl restart smartd
sudo systemctl status smartd --no-pager

Stop smartd from re-alerting on stale temperature history while keeping real failures monitored. Add an explicit device line to /etc/smartd.conf rather than relying on DEVICESCAN, and track temperature changes instead of absolute values:

/dev/nvme0 -a -W 5,55,70 -m root -M exec /usr/share/smartmontools/smartd-runner

-W 5,55,70 reports raw temperature changes of 5 °C or more, logs at 55 °C, and escalates at 70 °C. Pick the last two against your own WCTEMP, not against ours.

Keep dated snapshots, because one report cannot show a trend:

# /etc/cron.weekly/smart-snapshot
#!/bin/sh
d=/var/log/smart; mkdir -p "$d"
for dev in /dev/nvme[0-9]; do
  [ -e "$dev" ] || continue
  smartctl -x "$dev" > "$d/$(basename "$dev")-$(date +%F).txt"
done

Redact serial numbers before posting any of this publicly. smartctl prints them by default, and they are the only field in a health report with no diagnostic value to the person reading it.

8. What this looks like on a healthy Mini PC

Mini PCs concentrate heat by design, so the question is not whether a home server NVMe runs warm, but where it settles. Our EQi12 unit sits at 38 °C on both sensors with zero cumulative warning minutes after sustained 50 GiB write and read passes — measured on a drive mounted inside a chassis smaller than a paperback. That is the result worth comparing against, and it is why we publish the raw log rather than a green health icon.

If your drive sits above 70 °C at idle, the fix is almost always physical: unblock the intake, move the unit off a heat-generating neighbour, or add an M.2 contact heatsink with actual thermal contact. Throttling will protect the drive long before 0x02 becomes a media error, but a drive that throttles is a drive that is not delivering the throughput you measured on day one.

For the other half of the picture — sustained throughput, port-by-port USB behaviour and how NVMe, USB and network compare for real workloads — see the NVMe vs USB SSD vs network share comparison. If your concern is redundancy rather than a single drive’s health, the ZFS and RAID capacity planning guide picks up where drive health ends. Long-run behaviour, including what to log over a 12-hour soak, is covered in the EQi12 stability test. And if throughput collapsed at the same time the temperature warning appeared, rule out the interface first with the USB SSD stuck at 40 MB/s fix.

Paste any report — yours or ours — into the SMART and NVMe health report explainer to extract the fields that matter. It runs entirely in your browser. Our measurement method documents how captures like the one above are taken, what is redacted, and why some counters are published as unavailable instead of estimated.