This guide is part of Flash Myths, Tested, where I check one common belief about SSDs against the sources I’ve saved. This one asks whether an SSD fails with no warning.
An SSD can leave a trail of errors before it costs you data, but the trail is in counters inside the drive, and you only see it if some software reads them. Field studies I saved show that errors repeat. They also show that the usual reliability number for flash does not predict the uncorrectable errors that matter.
That makes the myth half true. Both halves rest on studies of data-center fleets. I ran no test of my own on this, so I’ve kept every claim to what those studies measured.
Where the myth comes from
Few people ever open an SSD’s health log. Only the end of the trail reaches them: a file that will not open, a read that fails, a drive that vanishes from the list. Behind that, the drive has been managing its own faults. In the Google fleet study, a drive declared a block bad after a final read error, a write error or an erase error, then remapped it. Erase and write errors were less common than final read errors, so most bad blocks were found by a read, which is the kind of error the host sees.
Where the myth comes from
A bad block is found three ways and retired inside the drive
What a drive does when a block fails, and which find the host can see
Figure 1 draws that path. A bad block is found by one of three errors, and the drive removes it from future use, so only the read branch is likely to reach the host. That study also found flash drives replaced less often than hard drives, but with a significantly higher rate of problems that reach the user, uncorrectable errors among them. From the owner’s seat that can feel like no warning at all. The counting happened inside the drive, and the owner never looked.
What the field studies show
Two data-center studies give the best numbers I have. Google’s covers ten drive models over six years of production use. Facebook’s covers the SSDs in its own fleet. Both count errors, bad blocks and repairs. Neither measures desktop use, and that limit comes back below.
What the field studies show
A drive that just had an error is far likelier to have another
Chance of an uncorrectable error in a drive month, by what happened the month before
Figure 2 shows the clearest warning sign. In the Google data, the chance of an uncorrectable error in the month after another one was nearly 30%, against 2% in a random month. A final write error, a meta error or an erase error raised the chance by more than 5 times, which puts it above 10% by my arithmetic. Facebook’s fleet agrees: of the SSDs that had an error in the first of two recent weeks, 99.8% had one in the second. A 30% chance still means the likelier outcome in any one month is no second error, so a repeat is a strong sign without being a certainty.
What the field studies show
Errors reach many drives, but few are replaced
Share of drives that met each event in their first four years, lowest to highest model
Figure 3 shows how common these events are across the ten Google models. In their first four years, 30 to 80% of drives grew a bad block and 20 to 63% had at least one uncorrectable error, which touched 2 to 6 of every 1,000 drive days. Far fewer drives left service. For most models, 6 to 9% needed a repair, and about 5% were replaced for good. The Google study’s two worst models reached about 10%.
Bad blocks give the sharpest sign of a bigger problem. Drives tended to have either fewer than a handful of bad blocks or a large number. After 2 to 4 bad blocks there was a 50% chance that hundreds more would follow, and the authors suggest that could be used to predict a chip failure. Between 2 and 7% of drives developed bad chips in four years.
Where the warning falls short
The number most often quoted for flash reliability is the raw bit error rate, and in the Google data it did not predict uncorrectable errors. The authors also say the uncorrectable bit error rate is meaningless in the field, since uncorrectable errors did not track how much data was read.
Wear is not a clean countdown either. Both the raw bit error rate and the number of uncorrectable errors grew in a straight line with program/erase cycles, with no sudden spike when a drive passed the vendor’s rated limit, within the ranges seen in the field. Age also mattered on its own, apart from use.
Where the warning falls short
Failure does not climb in a straight line with use
Shape of the failure pattern on most platforms in a large SSD fleet: shape only, no values
Figure 4 draws the shape the Facebook fleet showed. Failure did not rise steadily with the data written. On most platforms it rose in an early detection period, fell in an early failure period, then rose again through the rest of the drive’s life. The NVMe health log has a wear number, Percentage Used, and the specification calls it a vendor estimate. A value of 100 means the estimated endurance is used up, which may not mean the drive has failed, and the value can go above 100. Treat it as a planning number. It does not count down to a failure. My own readings of it are in the wear-out myth.
I can’t say how often a desktop drive dies with every counter clean. Both fleets are data centers, and both studies count errors, bad blocks and repairs. Neither counts sudden deaths. I don’t have a saved source that does, so I’m giving no share. I can give one unmeasured case of my own, which says nothing about a share. I had an SSD that held a photo library. One day I had trouble accessing the volume, I rebooted, and the SSD was gone. Trouble with the volume came first, and then the drive vanished after the reboot.
What is actually true
A drive does not go from fine to dead in one step. Cells wear, blocks start to fail reads, programs or erases, and the firmware retires them and swaps in spares. Part 7 covers that retirement, and Part 8 walks through how error-correction trouble escalates stage by stage.
What is actually true
Each stage of failure has a field in the health log
Steps a drive goes through, and the NVMe health log field that reports each
Figure 5 sets each field beside the step it reports on. The results show up in the NVMe health log, and the table below gives each field’s meaning and when it moves.
| Health log field | What it reports | When it moves |
|---|---|---|
| Critical Warning | One bit each for spare below threshold, temperature, reliability degraded by media or internal errors, media read-only and volatile backup failure | Any bit set |
| Available Spare | Reserve blocks left, 100% on a new drive and falling as blocks are retired | Falling toward its threshold, which sets bit 0 of Critical Warning |
| Media and Data Integrity Errors | A count of unrecovered data integrity errors, including uncorrectable ECC, CRC checksum failure and LBA tag mismatch | Anything above zero |
| Percentage Used | The vendor’s estimate of endurance used | A reading of 100 may not mean failure |
A drive can raise an asynchronous event to the host when a Critical Warning bit is set, and the specification allows it. Whether you see anything depends on software that listens for it or reads the log.
What to do
Read the health log now and then, before anything breaks. Treat the first uncorrectable error as the signal to copy your data off, because that is the point where the next one becomes much likelier. Treat Available Spare falling toward its threshold the same way.
What to do
Act on a health log signal, and keep a backup either way
Three health log signals and the move that fits each
Figure 6 pairs each signal with its move. Don’t panic at a Percentage Used of 100, and don’t take a low reading as a promise. Keep a backup either way, and read the health log before anything breaks.
