The NVMe Critical Warning byte is the single most important health signal on an NVMe drive. Unlike ATA SMART’s scattered attribute IDs, this one byte consolidates five distinct critical conditions into a compact bitmask. Most operators who find this article have just seen a non-zero value from smartctl and need to know which bit is set and what to do about it.
The field is byte 0 of NVMe Log Page 0x02 (SMART/Health Information Log). Bits 0 through 4 are defined by the NVMe specification; bits 5 through 7 are reserved. Each bit represents an independent condition, so evaluate them individually. 0x00 means no active warnings. 0x09 means two conditions are active simultaneously (bit 0 plus bit 3).
Each bit has its own severity. Bit 3 (read-only mode) is an emergency. Bit 2 (reliability degraded) may be a false positive on some Samsung drives. Bit 1 (temperature) may be transient. Treating all non-zero values the same way produces alert fatigue or overreaction.
What it is and why it matters
smartctl reads byte 0 of the SMART/Health Information Log via the NVMe Get Log Page command and prints it as a two-digit hex value:
Critical Warning: 0x00
When any Critical Warning bit is set, smartctl also reports the SMART overall-health self-assessment as FAILED. This happens regardless of which bit is set or how severe the underlying condition is. A Samsung drive with bit 2 set (warranty-expiry indicator, zero media errors) shows the same FAILED status as a drive with bit 3 set (read-only mode, actual emergency). Operators who only check PASSED/FAILED cannot distinguish between these situations.
# Read the Critical Warning byte and surrounding health context
smartctl -A /dev/nvme0n1 | grep "Critical Warning"
How it works
The Critical Warning field occupies a single byte at offset 0 of the SMART/Health Information Log.
flowchart TD
BYTE["Critical Warning: 0xNN"] --> DECODE["Convert hex to binary, check each bit"]
DECODE --> B0["bit 0 set?"]
DECODE --> B1["bit 1 set?"]
DECODE --> B2["bit 2 set?"]
DECODE --> B3["bit 3 set?"]
DECODE --> B4["bit 4 set?"]
B0 -->|"0x01"| S0["Available spare below threshold"]
B1 -->|"0x02"| S1["Temperature above critical"]
B2 -->|"0x04"| S2["Subsystem reliability degraded"]
B3 -->|"0x08"| S3["Media in read-only mode"]
B4 -->|"0x10"| S4["Volatile backup device failed"]To decode the hex value manually, convert it to binary and check each bit position:
| Hex value | Binary | Bit(s) set | Meaning |
|---|---|---|---|
| 0x00 | 00000000 | none | No active warnings |
| 0x01 | 00000001 | bit 0 | Available spare below threshold |
| 0x02 | 00000010 | bit 1 | Temperature above critical threshold |
| 0x04 | 00000100 | bit 2 | NVM subsystem reliability degraded |
| 0x08 | 00001000 | bit 3 | Media in read-only mode |
| 0x10 | 00010000 | bit 4 | Volatile memory backup device failed |
| 0x09 | 00001001 | bits 0, 3 | Spare exhausted and read-only |
| 0x14 | 00010100 | bits 2, 4 | Reliability degraded and backup failed |
Multiple bits set simultaneously is normal when conditions compound. A drive that exhausts its spare pool (bit 0) and then enters read-only mode (bit 3) reports 0x09. Evaluate each bit independently because each has its own severity and response procedure.
The nvme-cli tool reports the same field as a decimal integer: critical_warning : 0. Be aware of the format difference when correlating across monitoring systems.
The five defined bits
Bit 0 (0x01): Available Spare below threshold. The spare block pool has dropped below the vendor-defined Available Spare Threshold (typically 10%). The drive can no longer guarantee enough reserve capacity for future bad blocks. This is a planning signal: order a replacement. It does not mean the drive is failing right now, but the runway is short. Correlate with the Available Spare percentage and its rate of decline.
Bit 1 (0x02): Temperature above critical threshold. The drive’s Composite Temperature has exceeded a critical thermal limit. NVMe drives thermally throttle before this point, so bit 1 means throttling has failed to contain the temperature rise. This can be transient (burst workload with inadequate cooling) or persistent (fan failure, detached heatsink). Check Warning Composite Temperature Time and Critical Composite Temperature Time for cumulative exposure above thresholds.
Bit 2 (0x04): NVM subsystem reliability degraded. Firmware has detected media-related or internal errors that degrade overall subsystem reliability. The signal is opaque: the NVMe specification does not define what internal conditions trigger it. Correlate with Media and Data Integrity Errors. If media errors are zero and Available Spare is healthy, this may be a firmware-level warning that is not yet user-impacting.
Samsung consumer NVMe drives (960 EVO, 970 EVO Plus, 980, and others) commonly set bit 2 when Percentage Used exceeds 100%, even when Available Spare is still 100% and Media and Data Integrity Errors are zero. Samsung’s firmware appears to use this bit as a warranty-expiry indicator rather than a genuine reliability signal. This is the most common source of false-positive Critical Warning alerts in the field.
Bit 3 (0x08): Media placed in read-only mode. The drive can no longer safely accept writes and has placed itself in read-only mode as a data protection measure. Reads still work, but all write operations will fail. This is typically permanent and non-recoverable. Immediate data evacuation is required.
Bit 4 (0x10): Volatile memory backup device failed. The drive’s power-loss protection hardware (supercapacitors or battery) has failed. Data in the volatile write buffer is no longer protected against unexpected power loss. The drive functions normally under stable power, but an unsafe shutdown now risks data-in-flight corruption. Only relevant for enterprise drives with PLP (Power Loss Protection).
Where it shows up in production
The Samsung bit 2 false positive is the most common reason operators search for this topic. The pattern is recognizable when you read the full health log:
# Check all relevant fields together to distinguish real failure from false positive
smartctl -A /dev/nvme0n1 | grep -E "Critical Warning|Available Spare|Percentage Used|Media and Data"
False-positive signature:
- Critical Warning:
0x04 - Available Spare: 100%
- Available Spare Threshold: 10%
- Percentage Used: above 100%
- Media and Data Integrity Errors: 0
This combination means the drive is past its rated endurance but not actually failing. The firmware sets bit 2 as a notification that warranty coverage has ended. The drive may continue operating for months or years. The NVMe specification explicitly allows Percentage Used values above 100%, up to a maximum of 255%.
Suppressing false-positive bit 2 alerts
smartmontools 7.5 reportedly introduced the -H MASK directive for smartd.conf, which lets operators mask specific Critical Warning bits while still monitoring the rest:
/dev/nvme0 -H 0x04 -l error
This configuration is intended to suppress alerts for bit 2 while keeping the other bits active. Bits 0, 1, 3, and 4 still trigger alerts normally.
Before this feature, the workaround was to add the device with -d ignore to smartd.conf, which disabled all monitoring for that device. That is a blunt instrument: you lose visibility into bits 0, 1, 3, and 4 as well. If you are running older smartmontools and cannot upgrade, alternatives are limited. You can disable smartd monitoring for the device entirely, or build a custom wrapper script that parses the full smartctl output and applies your own logic.
Bit 3 and BIOS boot refusal
Some UEFI or BIOS implementations refuse to boot from an NVMe drive that reports FAILED health status. Samsung drives with bit 2 set can cause servers to halt at POST, requiring manual intervention (typically pressing F1) to continue. This is particularly painful in remote or lights-out environments.
If this happens, the options are:
- Confirm via full smartctl output that the drive is not actually failing (zero media errors, full Available Spare)
- Replace the drive if the BIOS boot refusal is unacceptable in your environment
Severity by bit
Not all bits warrant the same response:
| Bit | Condition | Default severity | Escalate to PAGE when |
|---|---|---|---|
| 0 | Spare below threshold | TICKET | Available Spare at 0% AND Media Errors increasing |
| 1 | Temperature critical | TICKET | Sustained above CCTEMP with no recovery |
| 2 | Reliability degraded | TICKET | Corroborated by Media Errors, Available Spare falling, or bit 3 active |
| 3 | Read-only mode | PAGE | Always. Hardware-enforced, no false positive |
| 4 | Backup device failed | TICKET | Combined with unsafe shutdown events |
PAGE for bit 2 only when corroborated by at least one of: Media and Data Integrity Errors increased, Available Spare below threshold and falling, or bit 3 also active. Without corroboration, bit 2 alone is a TICKET.
Bit 3 is always PAGE. There is no false-positive scenario for read-only mode. The drive’s firmware has made a hardware-enforced decision to refuse writes, and no configuration change or firmware reset clears it under normal operation.
Signals to watch in production
| Signal | Why it matters | Warning sign |
|---|---|---|
| Critical Warning byte | Consolidated alarm for five conditions | Any non-zero value; decode to specific bits |
| Bit 0 (0x01) | Spare pool exhaustion | Available Spare declining toward threshold |
| Bit 1 (0x02) | Thermal runaway | Composite Temperature above CCTEMP |
| Bit 2 (0x04) | Reliability degradation or false positive | Correlate with Media Errors to distinguish |
| Bit 3 (0x08) | Read-only mode, emergency | Write operations failing at OS level |
| Bit 4 (0x10) | PLP hardware failure | Unsafe Shutdowns count increasing |
| Available Spare | Underlying condition behind bit 0 | Declining trend, especially below 10% |
| Media and Data Integrity Errors | Underlying condition behind bit 2 | Any non-zero or increasing count |
| Percentage Used | Context for Samsung false positives | Above 100% on Samsung drives |
| Composite Temperature | Underlying condition behind bit 1 | Above WCTEMP or approaching CCTEMP |
How Netdata helps
- Per-second collection of the Critical Warning byte shows bit transitions immediately rather than on a 5-minute polling interval.
- Correlate bit 0 with the Available Spare trend and bit 2 with Media and Data Integrity Errors to distinguish genuine failures from Samsung false positives within seconds of the bit being set.
- ML anomaly detection on Available Spare rate of change can surface the cliff-edge exhaustion pattern before bit 0 fires.
- Temperature dashboards correlate bit 1 with Composite Temperature and thermal time counters to show whether the condition is transient or persistent.
- Alerting on individual bits rather than the aggregate byte prevents the “any non-zero value means PAGE” pattern that causes alert fatigue across mixed NVMe fleets.
Related guides
- Current_Pending_Sector non-zero: unreadable sectors and I/O latency spikes
- SMART says PASSED but the drive is failing: why the health check lies
- 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 Percentage Used at or above 100%: rated endurance consumed
- Offline_Uncorrectable climbing: permanent data loss at the media level
- SMART overall-health self-assessment: FAILED is the drive’s own death notice
- Raw_Read_Error_Rate looks enormous: the Seagate false alarm explained
- Reallocated_Event_Count vs Reallocated_Sector_Ct: reading both together
- Reallocated_Sector_Ct rising: the drive is burning through its spare pool