SSD health

Mac SSD Endurance, Explained: Disk Writes, TBW, Swap & Wear

By CoreGuard · Jul 24, 2026 · 21 min read

Is my Mac's SSD wearing out from writes?

Writes do use up endurance — but a high write total, on its own, doesn't show your SSD is anywhere near wearing out. "SSD endurance" is how much writing the flash can take before it wears out; on a Mac you read it from the drive's own NVMe counters, watch a trend instead of a snapshot, and accept that no honest tool turns it into a failure date. The signals that actually warn you are any media errors, a set Critical Warning bit, or a falling spare reserve — not the number of terabytes written. This guide defines the counters once, shows a real dated reading off my own machine, and links out to a deep dive for each source of writes.

The short version

A Mac SSD has no single "health" number. Wear is read from the drive's own NVMe health log — Data Units Written (a host odometer), Percentage Used (a coarse vendor estimate), Available Spare and Media Errors (per NVM Express and SNIA).
A real dated reading off my own Apple-silicon Mac: 34.1 TB written on Jul 14, 34.9 TB on Jul 24 — +0.84 TB in ten days — while Percentage Used stayed pinned at 2% the whole time. The fine counter moves daily; the endurance estimate barely twitches.
Apple publishes no consumer TBW for its SSDs, so no honest tool turns a write total into "% of life used" or a failure date (NVMe: reaching 100% "may not indicate" failure).
Host writes are not flash writes: the controller's write amplification, garbage collection and wear-levelling are invisible to Data Units Written (SNIA). Copy-on-write is not "write twice."
Deleting files, caches, snapshots or Docker images frees space but never un-writes endurance already spent. They are different accounts.

A Mac SSD reports several NVMe counters, and each measures a different thing. There is no single "health" number — reading one as if it were another is where the myths start.

What "SSD endurance" actually means on a Mac

Flash memory wears out by being written to. Each cell can survive a finite number of program/erase cycles — modern Mac SSDs are estimated at around 3,000 cycles per cell before wear-out (Howard Oakley, Eclectic Light). Endurance is the drive's budget of writes before that becomes a risk. The catch is that you can't watch it directly. What you can watch are proxies the controller exposes over NVMe, and the whole skill is knowing which proxy answers which question — and which questions have no honest answer at all.

Three limits shape everything below, so I'll state them once, up front:

Apple publishes no consumer TBW. There is no official "rated writes" figure for a Mac's internal SSD (Oakley, 2022). Any "you've used X% of your drive's rated life" number for a Mac is borrowing a figure Apple never gave.
Host writes are not flash writes. The counter you can read totals what the operating system sent to the controller. What the flash physically endures is usually higher — occasionally lower on a controller that compresses — and by how much is hidden (SNIA calls the gap write amplification).
No counter is a countdown. The drive's own endurance estimate moves in whole percent and, per the NVMe spec, hitting 100% "may not indicate" the drive has failed. It is an estimate, not a fuel gauge.

One dated reading everything else quotes

Here is the whole point in two rows. These are real values from the internal SSD of the Apple-silicon Mac I'm writing on (an APPLE SSD AP0512R, 512 GB), pulled read-only with a current smartmontools:

$ smartctl -a /dev/disk0        # smartmontools 7.5
Data Units Written:  66,712,577 [34.1 TB]   # 2026-07-14
Data Units Written:  68,353,938 [34.9 TB]   # 2026-07-24  (+0.84 TB)
Percentage Used:     2%                      # unchanged on both dates
Power On Hours:      1,421  ->  1,488        # +67 powered hours
Available Spare:     100%                    # both dates (threshold 99%)
Critical Warning:    0x00                     # 2026-07-24 (no reliability/read-only/spare flags set)
Media and Data Integrity Errors: 0           # 2026-07-24 only (this field wasn't recorded on 2026-07-14)

In ten days this drive took about 840 GB of host writes — an unusually heavy stretch (Docker, VM images, builds) on a working machine. Over that same window its endurance estimate didn't budge. That gap is the reason "years left" needs many months of data and still can't produce a date.

Read the two rows together and the split is obvious. Data Units Written is fine-grained: it climbed by 1,641,361 raw units — about 840 GB — in ten calendar days, roughly 84 GB/day on a deliberately write-heavy machine. Percentage Used is coarse: it registered exactly zero movement, because Percentage Used only moves in whole-percent steps and both readings happened to fall in the same 2% bin. (A reading already near a boundary could tip on far less; whole-percent steps just don't resolve day-to-day writes — they don't fix a set number of terabytes per percent.) Neither number is a defect. Together they show why you measure a rate and a slope, never a single "how much have I used" snapshot.

One more thing this reading settles, because our own older articles were cautious about it. On a current smartmontools (7.5 and up), smartctl -a /dev/disk0 can read the internal Apple-silicon SSD's NVMe health log — I just did, and every field above came straight from it. That wasn't reliably true on older tooling, which is why you'll still see "the internal SSD doesn't expose this on Apple silicon" advice around. Treat it as version-dependent, not impossible: if a read is denied, re-run with sudo; if the health log still isn't exposed on your particular Mac, record that limitation instead of inventing a number — Activity Monitor's per-process Bytes Written is the always-available host-side fallback. External USB and Thunderbolt enclosures are the genuinely hard case, because many bridge chips don't pass SMART through at all (that's its own article).

One scope note before the glossary: the NVMe field names and the ×512,000 arithmetic in this guide describe Apple-silicon Macs, whose internal SSD is NVMe. An older Intel Mac with a SATA SSD reports different, vendor-specific attributes (often Total_LBAs_Written) in units that vary by model — the ideas carry over, the exact field names and math don't.

The counters, defined

Half the SSD-wear panic on the internet is a vocabulary problem — one counter read as if it were another. Here is the whole glossary this cluster uses, each in one honest sentence:

Data Units Written (DUW) — the NVMe controller's lifetime host-write counter, reported in thousands of 512-byte units, so one raw unit is 1,000 × 512 = 512,000 host bytes; it covers the whole device and counts what the host sent, not physical NAND writes.
TBW (terabytes written) — used two ways people constantly conflate: the actual lifetime host total (which your Mac exposes) versus a manufacturer's rated endurance, a JEDEC-defined warranted minimum (JESD218), not a failure point — and Apple publishes no rated TBW for its SSDs at all.
Percentage Used — the drive's own vendor-specific estimate of consumed endurance, in 1% steps; it can exceed 100, and the NVMe spec says reaching 100 "may not indicate" failure. Its slope over months is the signal; one reading is not.
Power-On Hours (POH) — cumulative hours the drive has been powered; the age-and-intensity denominator you divide writes by to get a rate, not a wear figure by itself.
Available Spare — the percentage of the controller's reserve blocks still available, paired with a threshold; a value falling toward that threshold is a genuine warning, unlike a slowly rising Percentage Used.
Media and Data Integrity Errors — the count of unrecovered integrity events; zero is normal, any non-zero value deserves a backup and a look (a rising count means it is recurring), and NVMe's separate Critical Warning bit flags conditions like degraded reliability or read-only media.
Write amplification — SNIA defines it as physical NAND writes ÷ host writes; the controller's garbage collection, wear-levelling and relocation usually add real flash writes the host counter never sees, so physical NAND wear is normally some multiple of DUW — but the exact relationship is hidden and controller-dependent (a few controllers even compress, writing less), so DUW is not a clean measure of NAND wear.
Swap — disk-backed virtual memory macOS uses only for the overflow that in-RAM compression can't absorb; "Swap Used" in Activity Monitor is a live allocation gauge that rises and falls, not a wear odometer.
Copy-on-write (APFS) — APFS writes a changed block to a new location and re-points metadata instead of overwriting in place; it is not "write everything twice" — it's what let Apple retire the HFS+ journaling that actually did double-write.
APFS snapshot — a point-in-time reference that retains the blocks a volume had at that instant so they aren't freed; it costs space as the live volume diverges, but it is not a fresh duplicate write of that data.
Sparse file — a file (like Docker.raw) whose apparent size is a provisioned maximum while only written blocks occupy the disk; a "100 GB" sparse file is usually provisioned, not 100 GB actually written.

How much writing is "normal"?

There is no universal safe GB-per-day for a Mac SSD, and anyone selling you a green/amber/red threshold is guessing. A daily total has no shape on its own. Read three things together: the short-term write rate, that specific Mac's own baseline, and the long-term slope of Percentage Used. A hundred gigabytes spread evenly across a day is about 1.2 MB/s and invisible; the same hundred gigabytes in a fifteen-minute import is a brief 110 MB/s burst that then stops. Same total, completely different story — see how much SSD writing is normal on a Mac for the burst-vs-plateau-vs-sustained-anomaly taxonomy.

To act on a number you have to attribute it, and a device counter can never name a process — it only knows the drive wrote. The honest attribution chain runs process → path → device → time: Activity Monitor's Disk tab names running processes and their accumulated writes (compare two readings minutes apart to see whose counter is climbing now), sudo fs_usage shows live filesystem events and paths, and the NVMe counter brackets the whole-device total for the same window. Join them by time and workload; don't equate one layer's byte count with another's. The full method is in which app is writing to my Mac's SSD, and the special case where the kernel_task row shows enormous writes — which is accounting, not a culprit — is its own explainer.

Where the writes come from

When a write rate looks high, it's almost always one of a handful of normal, explainable sources. None of them is a reason to disable a macOS feature to "save" the drive:

Swap. macOS absorbs most memory pressure by compressing pages in RAM; only the overflow becomes disk-backed swap. Chronic red memory pressure is worth fixing by reducing demand or choosing more unified memory on your next Mac — but swap is not "killing" your SSD, and "Swap Used" is an allocation gauge, not a wear total. Detail: is macOS swap wearing out my Apple-silicon SSD.
Spotlight re-indexing. A macOS update makes Spotlight rebuild its indexes: mds_stores becomes a prominent writer for hours. Healthy catch-up trends down across comparable windows; a stuck loop stays flat-high after the migration finished. Tell them apart — don't disable indexing, which is itself write-heavy. Detail: why is my Mac writing to disk after a macOS update.
Browsers. "Chrome wrote 100 GB" is usually cache + IndexedDB + extensions + crash-recovery + service-worker storage, not one runaway leak. Isolate the component; don't blanket-disable caching (which just moves writes around). Detail: why is Chrome writing so much to my Mac's SSD.
Docker and VMs. A big Docker.raw is usually a provisioned sparse file, not bytes written; pulls, no-cache builds, database fsync and unrotated container logs are what actually write. Pruning frees space inside the VM but never un-writes endurance. Detail: why is Docker.raw so huge on my Mac.

The mechanism: copy-on-write and snapshots

Two APFS features get blamed for "secret" SSD wear, and both accusations are backwards. APFS is copy-on-write: when a block of a file — or of the filesystem metadata — changes, APFS writes the new version to a freshly allocated block and re-points the metadata, instead of overwriting in place (Oakley on copy-on-write). People read that as "writing everything twice." It's the opposite: copy-on-write is exactly what let Apple retire HFS+ journaling, and it was journaling that double-wrote. Copy-on-write changes where a write lands and re-points metadata; a single change can still touch filesystem-tree and object-map structures alongside the data block, but it avoids the blanket double-write that HFS+ journaling imposed.

An APFS snapshot is a point-in-time reference, not a copy. Creating one records the metadata and the set of extents needed to reinstate the volume, and completes in hundredths of a second (Oakley on APFS snapshots) — it does not immediately duplicate that data into new flash. What a retained snapshot changes is housekeeping: as the live volume moves on, the older blocks the snapshot still references are kept rather than freed for reuse. Snapshots are a normal, mostly beneficial part of macOS — Time Machine takes a local snapshot of each backed-up volume every hour and deletes them once they're over 24 hours old, and the Signed System Volume your Mac boots is itself a snapshot. A snapshot's storage cost grows only as the volume diverges from it.

So when local snapshots eat disk space and you delete one, the filesystem frees those retained blocks for reuse — but freeing space is not reclaiming endurance. The program/erase cycles already spent writing those blocks are gone; deleting the snapshot cannot un-write them. That's why "delete snapshots to save your SSD" is the wrong frame: snapshots are self-managing and useful, and the honest job is to measure and explain, not to prune normal macOS behavior.

Host writes are not the whole story

The number everyone watches — Data Units Written — is host traffic, not flash traffic. NVMe defines it as 512-byte units the host wrote to the controller, reported in thousands, metadata excluded (NVM Express base specification). What the NAND actually programs is usually larger, because of write amplification: FTL remapping, garbage collection, and small or unaligned writes. SNIA defines the write-amplification factor as physical NAND bytes ÷ host bytes — a host gigabyte that becomes three gigabytes of NAND is a factor of three. NAND-level counts are vendor telemetry, not a standard NVMe field, so that gap stays hidden on most drives. Practically: treat Data Units Written as the one host-side number you can read and trend — usually below the physical NAND total because of amplification, occasionally above it on a controller that compresses, but never a stand-in for the exact wear the flash has endured.

Data Units Written counts what the host sent the controller. The flash usually writes more — how much more is the drive's private business — so a host write total isn't the physical wear figure, just the one you can read.

The long game: wear trend and "years left"

Can anything tell you how many years your SSD has left? No honest tool can give a date. What two or more dated Percentage-Used readings support is a conditional trend: "at this pace, one more percent takes roughly N months," always carried with explicit uncertainty. It's a scenario, not a prophecy, and it changes the moment your workload does — which is exactly why my own drive sat at 2% across the ten-day window above and gave no slope to project from yet.

The scale is reassuring once you have a reference. Oakley measured a seven-year-old 1 TB iMac Pro that had written about 150 TB — roughly 21 TB/year, just under 60 GB/day — against a generalized ~3,000-cycle assumption — his point being that a workload like that isn't close to an endurance worry (Eclectic Light). That's Oakley's own estimate, not a measured Apple-SSD cycle count — host writes don't reveal NAND cycles — so take it as rough context for scale, not a projection for your drive and not a universal 60 GB/day baseline. On that measured machine, the failure mode people fear — writing a consumer SSD to death in normal use — was nowhere in sight; a handful of measured examples is context, not a population statistic. The honest limits still bind: you cannot convert Data Units Written into "percent of rated life" on a Mac because Apple publishes no rated TBW, and a rising Media-and-Data-Integrity-Errors count or a falling Available Spare is a real warning where a high write total, by itself, is not. The dedicated walk-through is how long will my Mac's SSD last.

Reading a used Mac's SSD

Buying or selling second-hand, the same counters become provenance evidence — as long as you read them as evidence, not a verdict. They are different clocks:

Percentage Used — an estimate of how much of a manufacturer-guessed budget was consumed; 6% used means light estimated wear, not a pass mark.
Data Units Written / TBW — the host odometer; a high total on few hours reads write-heavy, a modest total across many hours reads as a light lifetime average (an average, not proof the use was evenly spread).
Power-On Hours and power cycles — age, intensity and handling pattern, not wear; unsafe shutdowns hint at how it was treated.
Calendar age — a fourth clock again, independent of all of the above.

Read together they corroborate how a machine was used. What they never license is a claim that the drive "will fail on date X," that it is "genuine" or "has been replaced," or that it passes or fails — and because Apple publishes no per-model TBW, you can't derive a clean "% of rated life" at all. Pair this with the buyer's walk-through in how to check a used MacBook before buying, and with what SMART can and can't tell you for the failure side.

When it's actually failing (and when it isn't)

This guide is about wear, not diagnosis — it doesn't replace the failure playbook, it points at it. The short version: stock macOS shows only a coarse SMART status (Verified / Failing) in Disk Utility and System Information, and "Verified" is a pass/fail bit, not a clean bill of health — drives fail without warning. The fields that actually signal trouble are the ones above: any non-zero Media-and-Data-Integrity-Errors count (rising means it is escalating), a set NVMe Critical Warning bit, and an Available Spare falling toward its threshold. A large Data Units Written total, on its own, is not a failure signal. For the full treatment — including why "Verified isn't a guarantee" — read is my Mac's SSD failing. And if the drive in question is external and reports nothing, that's usually the USB bridge, not the disk: your external drive may be fine, your Mac just can't ask. Counterfeit drives are their own trap — the evidence a fake can't fake is in a fake SSD can copy the label.

Where CoreGuard fits

CoreGuard reads the same NVMe health log this article does and surfaces it in plain English — it observes and explains, and never cleans, prunes, or deletes anything to change a number. In keeping with the rule that seeing danger is always free: the SMART health status, a life-remaining figure derived from the drive's own Percentage Used, and a plain-English warning when a process is writing far more than usual — naming that process — are free. The power tools are Pro: the detailed per-app write timeline and history, the endurance readout (Data Units Written / TBW, power-on hours, raw SMART fields), the multi-reading wear trend, and an exportable condition report — the portable proof you hand a buyer or seller. The trend is always a conditional estimate with its uncertainty attached; CoreGuard never invents a failure date, because no honest tool can.

How to measure SSD wear on a Mac honestly

Identify the internal drive. Run diskutil list internal physical and use the identifier it reports (disk0 on most Macs). On Apple silicon that disk is NVMe, so the fields and ×512,000 math here apply; an older Intel Mac's SATA SSD reports vendor-specific attributes in different units.
Take a dated baseline. Run smartctl -a /dev/disk0 (add sudo if the first read is denied) and save the raw Data Units Written, Percentage Used, Available Spare and Media and Data Integrity Errors with the date and what the Mac was doing. If the health log isn’t exposed on your Mac, record that limit instead of inventing a number.
Attribute the writers, don't guess. For a live window, watch Activity Monitor's Disk tab per process and sample with sudo fs_usage — but treat those as accounting endpoints, not proof of NAND wear.
Close the bracket. Read Data Units Written again after the window and compute (later − earlier) × 512,000 to get approximate host bytes for that period — every writer on the device, not one app.
Compare to that Mac's own baseline. Ask whether the slope is settling back toward normal after a burst, or staying high after the workload ended. Only the second case is worth digging into.
Never extrapolate a date. Record uncertainty; any non-zero Media-and-Data-Integrity-Errors count, a set Critical Warning bit, or a falling Available Spare is a real warning — a high write total, by itself, is not.

Frequently asked questions

How many TB can a Mac SSD write before it wears out?

Apple does not publish a consumer TBW rating for its SSDs, so there is no official number to count down from. The drive keeps its own endurance estimate as the NVMe Percentage Used field, which moves in 1% steps and can pass 100 without failing. Treat write totals as evidence to watch, not a fuel gauge that hits empty on a known date.

Is macOS swap killing my SSD?

No. macOS handles most memory pressure by compressing pages in RAM, and only the overflow becomes disk-backed swap, which lands in the same whole-device write counter as everything else. Chronic red memory pressure is worth fixing by reducing demand or choosing more unified memory on your next Mac, but Swap Used is a live allocation gauge, not a wear odometer.

What is a normal number of GB written per day on a Mac?

There is no universal safe GB-per-day figure, because a daily total has no shape without context. Read the short-term write rate against that specific Mac's own baseline and the long-term slope of Percentage Used. Bursts from updates, backups, imports and indexing are legitimate and settle back down.

What does Percentage Used mean on an SSD?

It is the drive's own estimate of how much of its rated endurance it has consumed, reported in whole percent. It can exceed 100, and the NVMe spec says reaching 100 may not indicate that the drive has failed. It is a coarse estimate, not a countdown to a failure date.

Do Data Units Written equal how much my flash has actually worn?

No. Data Units Written counts host bytes sent to the controller, where one raw unit is 512,000 bytes; it is not the physical NAND writes after the controller's garbage collection and wear-levelling. SNIA calls that gap write amplification, and it stays hidden from the host counter.

Will deleting snapshots, caches or Docker images save my SSD's life?

No. Deleting files, caches, snapshots or disk images frees space, but it cannot un-write the endurance that was already spent when those bytes were written. Space and endurance are different accounts, and reclaiming one does not refund the other.

How do I check my Mac's SSD wear?

On Apple silicon a current smartmontools (7.5 and up) can read the internal NVMe health log with smartctl -a /dev/disk0 (add sudo if the first read is denied); older tooling often could not, so if your Mac still does not expose it, record that limit rather than guess, and note that external USB enclosures frequently pass no SMART at all. Note the Data Units Written, Percentage Used, Available Spare and Media and Data Integrity Errors, with a timestamp. One reading is a data point; a trend needs at least two dated readings.

Can any tool tell me how many years my SSD has left?

No honest tool can give a failure date. A conditional wear trend from two or more dated Percentage-Used readings can say that at the current pace one more percent takes roughly N months, always with explicit uncertainty. That is a scenario, not a prophecy, and it changes the moment your workload does.

Sources & further reading