Windows SSD Writes and Wear: How to Check Your Write Rate and NVMe Health

MakeUseOf’s Yasir Mahmood encountered exactly that mismatch: a substantial lifetime write total alongside a drive-reported Percentage Used reading of just 2%. His investigation offers a useful starting point for Windows users, provided we separate measured activity, estimated wear, and lifespan arithmetic.

What the 27TB figure actually measures​

Mahmood reported these readings from his SK hynix 512GB SSD:

These are observations from his laptop, not measurements independently reproduced on another system. The drive was also secondhand, so an unknown portion of its activity predates his ownership.

The raw write counter has a defined meaning. The NVM Express specification says the SMART/Health Information log’s Data Units Written field counts host-written data in thousands of 512-byte units, rounded upward. Each reported unit therefore represents 512,000 bytes; metadata is excluded.

Applying that definition gives:

53,562,572 × 512,000 bytes
= 27,424,036,864,000 bytes
≈ 27.4 decimal TB

That supports the report’s approximate total. For comparisons, keep the units consistent rather than subtracting a utility’s displayed “GB” number directly from a decimal-terabyte endurance figure.

It also matters that this is a host-write counter. Microsoft’s NVMe documentation describes data written by the host to the controller—not a count of how many times every individual flash cell has been rewritten. Describing the total as roughly 53 drive-capacity equivalents is useful arithmetic, but not a physical wear measurement.

A lifetime average is not today’s workload​

Dividing the reported 27.4TB by 6,536 power-on hours produces approximately 4.2GB per reported powered-on hour. Extending that rate across 24 hours gives about 100GB.

Neither calculation establishes that the laptop currently writes 100GB every calendar day. Both come from lifetime totals, including activity under a previous owner.

Mahmood’s Resource Monitor snapshot showed System, Registry, a Windows service host, Chrome, and CCleaner’s background service among the writers. Those observations identify activity during that inspection; they do not assign responsibility for years of accumulated writes.

Microsoft documents Resource Monitor as a real-time troubleshooting tool and explicitly recommends watching its Disk tab for a period of time to understand activity. A single busy moment is not a historical audit.

How to measure your own SSD write rate​

The practical approach is to establish a baseline before changing Windows settings.

CrystalDiskInfo’s developer documents support for SSD monitoring, including NVMe and some USB and RAID configurations. Support is not universal, so missing counters should not automatically be interpreted as zero activity or perfect health.

Use this measurement workflow:

1. Identify the correct drive. Record its model so subsequent readings concern the same SSD.
2. Save the starting readings. Note the date, total host writes, and available wear indicators. Keep the displayed units.
3. Use the PC normally. A representative interval is more useful than deliberately minimizing activity.
4. Repeat after several weeks. Subtract the starting total from the new total.
5. Divide by elapsed calendar days. That gives a practical daily average for that interval.

For example, a hypothetical increase of 600GB over 30 days means an average of 20GB per day. Unlike dividing a secondhand drive’s lifetime total by your ownership period, this measures an interval you actually observed.

If the increase seems unexpectedly large, investigate current writers using Microsoft’s documented Windows procedure:

1. Press Win + R.
2. Enter resmon and press Enter.
3. Open the Disk tab.
4. Observe activity during the workload associated with the increase.

The goal is to identify repeatable activity worth investigating—not to treat every disk write as a fault.

Hibernation adds writes, but file size is not write volume​

Mahmood had switched from sleep to hibernation about a year earlier. That makes hibernation relevant to his investigation, but does not establish how much of his lifetime total it caused.

Microsoft explains that hibernation saves system state to storage in compressed form. Fast Startup uses a different path: it logs off user sessions while preserving kernel state. Its documentation lists default hibernation-file sizes of 40% of physical memory for a full file and 20% for a reduced file. On a 16GB system, those proportions are approximately 6.4GB and 3.2GB. Neither allocation is a measurement of bytes written during every transition.

There is no need to disable a useful feature merely because its writes are visible. If you deliberately want to change it, open Command Prompt as administrator first.

If a custom file size prevents the reduced configuration, Microsoft documents running powercfg /hibernate /size 0, then retrying the reduced-type command.

To disable hibernation entirely, Microsoft documents powercfg.exe /hibernate off; use powercfg.exe /hibernate on to re-enable it. Disabling hibernation also removes hybrid sleep’s power-loss protection: Microsoft warns that data can be lost if power fails while hybrid sleep is enabled but hibernation is unavailable.

Why 2% used does not contradict 27TB written​

The report compares its total with a 300TBW estimate from specification databases, while acknowledging that SK hynix does not publish that rating for the exact OEM part. Consequently, the resulting “about 9%” calculation is conditional—not a verified manufacturer endurance assessment.

Percentage Used answers a different question. Microsoft defines it as a vendor-specific estimate based on actual usage and the manufacturer’s prediction of memory life. A reading of 100 means estimated endurance has been consumed, but does not necessarily mean failure; the value can exceed 100.

That makes the reported 2% useful context, not a guarantee of decades of service.

Likewise, the article’s roughly 25-year remaining-write-budget calculation depends on an unconfirmed endurance rating and an assumed future workload. It is a hypothetical projection, not a replacement date you can put in a calendar.

The sensible takeaway is less dramatic than the initial counter: measure the change, investigate persistent unexplained activity, and distinguish host writes from estimated wear. An SSD’s lifetime total is a useful odometer—not a countdown timer.