NVMe SMART Health Log Explained: Percentage Used, Available Spare, and the Fields That Actually Matter
Open an NVMe drive’s health report and the familiar SMART attribute list is gone. In its place is a short, standardized log — Critical Warning, Percentage Used, Available Spare, Data Units Written, Media and Data Integrity Errors — defined by the NVMe specification as Log ID 02h. The standardization is good news: these fields mean the same thing across brands in a way the old SATA attribute list never did, because SATA SMART carries a different, vendor-shaped attribute list. The catch is that much of the advice written about these fields gets their definitions subtly wrong, and the errors all push in one direction: panic earlier than the specification justifies, or about the wrong field entirely.
The fields, verified against the specification
| Field | What the specification says it is | Healthy pattern |
|---|---|---|
| Critical Warning | A bit field of current critical states; the bits are not persistent | 0x00 — any value above zero deserves decoding, not guessing |
| Composite Temperature | A value in Kelvins whose computation is implementation-specific; it may not represent the temperature of any physical point | Read it as the drive’s own summary, and compare against the drive’s thresholds rather than a universal chart |
| Available Spare | Normalized percentage, 0 to 100, of remaining spare capacity | Starts at 100 on a new drive; movement downward is the signal |
| Available Spare Threshold | The drive-reported level below which an event may be raised when spare falls under it | Whatever your drive reports — compare spare against this number, not a remembered rule |
| Percentage Used | A vendor-specific estimate of subsystem life used, updated once per power-on hour | Low and rising slowly; see the myth section before acting on any single value |
| Data Units Read / Written | Counts of 512-byte units, reported in thousands — one unit is 1,000 × 512 = 512,000 bytes | Convert before comparing with any capacity or endurance figure |
| Media and Data Integrity Errors | Occurrences where the controller detected an unrecovered data integrity error, including uncorrectable ECC, CRC checksum failure, or LBA tag mismatch | Zero; any appearance or growth is the log’s most serious counter |
| Error Information Log Entries | The number of error information log entries over the life of the controller | A separate counter from media errors; judge it with the error log itself, not as lost data |
| Unsafe Shutdowns | Incremented when a shutdown notification is not received before power is lost | Context: a rising count points at power habits or stability, not at worn flash |
Solidigm’s published byte map confirms how fixed this layout is: Critical Warning at byte 0, Composite Temperature at bytes 1–2, Available Spare at byte 3, its Threshold at byte 4, Percentage Used at byte 5, and the data-unit, power-cycle, power-on-hour, and unexpected-power-loss counters at defined offsets after that. When two tools disagree about an NVMe field, they are almost always disagreeing about presentation — hex versus decimal, raw versus converted — not about the underlying log.
Two myths the specification corrects
Myth one: Percentage Used is the share of the TBW rating you have burned. The specification’s own words are “a vendor specific estimate of the percentage of NVM subsystem life used,” based on actual usage and the manufacturer’s prediction of life. It is an estimate produced by the drive’s maker, not a division of your writes by a published TBW figure. One practical consequence follows directly from the definition: a value of 100 indicates the estimated endurance has been consumed, but may not indicate a subsystem failure, and the value is allowed to exceed 100, with anything over 254 displayed as 255. A drive at 100 has used up what its maker promised — a firm reason to have its replacement ready — but the number is the end of a warranty-style estimate, not a switch that turns the drive off.
Myth two: the spare threshold is 10 percent. Ten percent is a value many drives happen to report, which is how it hardened into a rule. The specification defines the threshold as a field the drive itself supplies: when Available Spare falls below the threshold indicated in that field, an event may occur. The correct comparison is always your drive’s spare against your drive’s threshold, both printed on adjacent lines of the same log. A drive reporting spare of 100 against a threshold of 10 and a drive reporting spare of 100 against a threshold of 0 are in the same health position; only the distance to each drive’s own line matters, and spare only starts to matter when it begins moving toward that line.
Media errors are not error log entries
These two counters sit near each other in most tools and get read as one escalating problem. They record different things. Media and Data Integrity Errors count unrecovered data integrity failures — the controller tried, its correction mechanisms failed, and data was not recovered intact. That counter belongs at zero, and growth in it is a backup-and-replace signal on its own.
Error Information Log Entries count entries in a separate log where the controller records error information over its life. An entry records that something was logged — invalid commands, aborted operations, and other events can land there — which is not the same claim as “data was lost.” That is why a real-world log can show a substantial entry count on a drive whose media-error counter is zero and whose overall assessment passes. The two counters answer two questions: media errors ask whether data has failed to survive; log entries ask whether the controller has had anything worth noting. Read the actual error log beside the health log before treating an entry count as damage, and treat any media error as damage without waiting for company.
Read your own log: the baseline procedure
- Pick one tool and keep it. smartmontools is free and runs on Windows, Linux, and macOS; CrystalDiskInfo presents the same NVMe log on Windows. Consistency matters more than the choice, because baselines only work when readings are comparable.
- Find the device name. In an administrator terminal, run smartctl --scan to list the drives smartctl can see, or smartctl --scan-open on Windows. Note the name it assigns your NVMe drive.
- Save the full health log as your dated baseline. Run smartctl -a followed by that device name, and save the output to a file named with the date — for example, nvme-baseline-2026-10-25.txt. On NVMe, that single command includes the health assessment, the SMART/Health Information log, and the error log.
- Record five fields in a note: Critical Warning, Available Spare, its Threshold, Percentage Used, and Media and Data Integrity Errors, plus Data Units Written for the calculation below. Because an SSD gives no audible warning as it wears — there are no moving parts to get louder — a saved baseline and a monitoring tool left running are the practical substitute for listening to a drive.
- Repeat monthly, and after any crash or power event. File each reading with its date. One reading is a photograph; two readings are a rate; three are a trend you can plan around.
What success looks like: you can produce, for your NVMe drive, a dated baseline and a current reading, state the distance between Available Spare and its own threshold, and point to the media-error count — all without relying on a percentage someone else’s article told you to fear.
One access caveat: if the drive sits behind a USB enclosure or certain RAID layers, the tool may not be able to pass NVMe commands through, and the log will be missing rather than empty. The log still exists; reading it then requires the drive on a direct M.2 connection or a stack that supports NVMe passthrough. A missing log is an access problem, not a health verdict.
Turn Percentage Used into a timeline: the wear-rate calculation
A percentage becomes useful when it has a rate. The arithmetic needs two of your own dated readings and nothing else. Suppose — as a worked example with round numbers, not a claim about any real drive — a baseline saved on 2026-04-25 shows Percentage Used at 12, and a reading six months later shows 15. The drive consumed 3 percentage points in 6 months: half a point per month. At that rate, the remaining 85 points represent roughly 170 months of the same usage before the estimate reaches 100. Run the same arithmetic on your real pair of readings. Three cautions keep the result honest. The estimate is vendor-specific, so the projection describes this drive’s own accounting, not a universal lifespan. The rate assumes your workload stays similar; a new video-editing habit rewrites it, which the next reading will show. And reaching 100 in the projection is a replacement deadline to plan around, not — per the specification — a predicted failure date. Use the same conversion discipline for Data Units Written: multiply the reported number by 512,000 to get bytes written by the host, so a reading of 10,000,000 data units is 5.12 terabytes of host writes — a figure you can compare against your own notes about how the machine is used.
The decision framework, in one pass
Work down the log in this order and stop at the first row that matches. Critical Warning above zero: decode it and back up today. Media and Data Integrity Errors above zero or growing: back up and plan replacement now. Available Spare falling toward its own reported threshold: the reserve is being spent; replacement moves from someday to scheduled. Percentage Used climbing faster than your wear-rate calculation predicted: your workload changed or the drive is wearing early; shorten the check interval. Everything else — a log-entry count, a handful of unsafe shutdowns after a power cut, composite temperature you have not compared with the drive’s own thresholds — is context to record in the baseline, not a verdict. The log rewards readers who compare it with itself over time and with its own specification, and it reliably misleads readers who compare single numbers against rules of thumb from a different drive, a different interface, or a different decade.
Questions owners ask about the NVMe health log
Percentage Used says 100. Is the drive dead? Not by that field alone. The specification says 100 means the estimated endurance is consumed but may not indicate a failure, and values above 100 are permitted. Treat 100 as “replacement should already be in hand and backups verified,” and let Critical Warning, spare, and media errors tell you whether the drive is actually in distress.
Why does one tool show different numbers from another? Usually presentation: hex against decimal, data units shown raw against converted terabytes, or a tool applying the old SATA attribute names to an NVMe log. Compare the five baseline fields in the same tool across time and the disagreement stops mattering.
Available Spare dropped from 100 to 99. Worry? Record it and watch the rate. Spare exists to be spent as cells retire; a single early step followed by stability is different from a steady march toward the drive’s own threshold, and only dated readings separate the two.
Can this log predict a sudden failure? No, and that limitation belongs in every reading of it. The log tracks wear, spare capacity, and recorded errors well; a controller or electronics failure can still arrive without any of these fields moving first. The log is an early-warning system for gradual decline, and backups remain the protection against everything else.