I’ve used CrystalDiskInfo for years on different computers to check the health status of my SSDs. Typically, when I open it and see the usual “Good,” I’m content enough to close it and carry on with other tasks. But this time, the total data written caught my eye. It was at 40513GB, simply far higher than I expected, and with no extra context, it felt like I was burning through my SSD’s lifespan very quickly.
This inspired some deep research. I discovered Windows measures SSD endurance in TBW (terabytes written) but rarely exposes that raw number. What was more surprising was that a large portion of the writes did not come from actions I had taken. They were mainly background Windows activities.
How I checked my SSD’s total writes
The number Windows tracks but never shows you
On CrystalDiskInfo, this data is labeled as Total Host Writes. It’s an element of the drive’s SMART data, a kind of internal telemetry it holds about itself. Even though it’s continuously logged, it’s not presented in any user-facing way. Once you open the tool, it displays a table of relevant drive attributes, and here are some attributes you should pay attention to:
Metric
What it shows
How to read it
Total Host Writes
Cumulative data written to the drive since manufacture
Compare against your drive’s TBW spec
Health %
Drive’s estimated remaining endurance
A rough guide, not a precise countdown
Power-on Hours
Total hours the drive has been running
Puts your write total in time context
Power Cycles
Number of times the drive has powered on
Optional; useful for laptops especially
The number of writes was already about 40.51TB. This figure became more significant when I looked up the SSD’s rated TBW on the manufacturer’s product page. With these figures, I could calculate how much of my SSD’s lifespan is left using a simple formula: Percent of rated lifespan used = (Total Host Writes ÷ TBW) × 100.
For perspective, the average user writes between 7–15TB per year, while consumer SSDs are rated at 300–600TBW. For example, a 1 TB drive rated at 600 TBW could last decades (roughly 40 years at typical consumer write levels), which implies that endurance wouldn’t be the factor that ends the drive. The number I had seen for my SSD still felt high even with this context.
Some budget or older drives may not surface some of these details, not even on CrystalDiskInfo.
The number looks scary, but it usually isn’t
Why SSD endurance doesn’t work the way most people think
Afam Onyimadu / MUO
I panicked when I saw the large write number. Even though this may be understandable, that panic was misplaced. TBW is not a hard expiry date, but more of a warranty-backed threshold. It’s the manufacturer simply guaranteeing a certain amount of data the drive will handle under normal conditions. However, SSDs will generally exceed this limit significantly, mainly because NAND cell degradation is a very gradual process, and writes generally get evenly distributed across the drive by wear leveling.
I’ve done a comparison of different consumer drives:
SSD Model
Interface
Capacity
TBW Rating
Samsung 870 EVO
SATA
1TB
600TBW
WD Blue SN580
NVMe (PCIe 4.0)
1TB
600TBW
Crucial P3 Plus
NVMe (PCIe 4.0)
1TB
220TBW
SK Hynix Platinum P41
NVMe (PCIe 4.0)
1TB
750TBW
From the above comparison, budget drives typically have a much lower TBW rating than mid-range options. This is an important detail if you plan to keep the drive for a long time. However, performance doesn’t degrade as you approach the TBW limit; it typically remains stable until cells actually fail. And that was the point that made the figures I saw for my drive less alarming. Even if a drive hits 85% of its rated endurance, its performance will remain identical to a newer drive carrying out normal tasks.
Power
N/A
Speed
560MB/s (read), 530MB/s (write)
Connection
SATA
Portable
No
Brand
Samsung
Capacity
500GB
The Samsung 870 EVO is a high-performance 2.5-inch SATA III internal solid-state drive (SSD) designed for consumers, creators, and IT professionals.
Where all those writes are actually coming from
Windows is never truly idle
Afam Onyimadu / MUO
The figures I saw were surprising, especially because I felt I hadn’t done any activities out of the ordinary. But that’s explained by the write traffic that Windows generates, totally independent of your activity.
Hibernation (hiberfil.sys) has the highest impact. When your PC hibernates fully, Windows writes nearly your entire RAM contents to disk. Fast Startup, which most Windows 11 machines use by default, works differently: it only hibernates the kernel session rather than your full RAM, producing a smaller file that typically lands around 40% of your installed RAM. On a 16GB system, that’s still roughly 6GB written every time you shut down.
Pagefile (virtual memory) also has a high impact. Windows uses the pagefile for virtual memory and manages its size dynamically. This file is constantly expanding and shrinking because of memory pressure, and that process generates significant background writes.
There is also some meaningful impact from the Windows Update cache. These are infrequent writes but can be as large as several gigabytes for major updates. Additionally, System Restore / Volume Shadow Copy (VSS) produces a reasonable number of writes.
Windows Search indexing produces some writes, and so does SysMain (Superfetch), even though the impact of these isn’t as much. With this understanding, it became clear why my system had recorded as much as 40TB of write.
Related
This simple DNS switch is always my first privacy recommendation
Your ISP sees every domain you visit, even over HTTPS.
The tweaks that actually made a difference—and the ones I left alone
Disabling background services is unnecessary and unrealistic for most drives. So I turned my attention to making changes that affect activities with the highest write volumes. This included totally disabling hibernation. This feature is not really needed on a desktop that never runs on battery, and you only have to run the command powercfg /h off on an elevated command prompt to turn it off.
I didn’t disable Search indexing, but narrowed it down to only folders I search in, like Documents and the Start Menu. However, I left SysMain untouched. I also kept VSS because it’s too much of a trade-off to lose restore points. Of all the changes, disabling hibernation is the most consequential because it writes the most to the SSD.
