How Much SSD Writing Is Normal on a Mac?

Everyone wants a number: is 100 GB a day fine? The honest answer is that no single GB/day is a pass/fail line — you read three things together, and I’ll show the whole method, counter math included, with real numbers off my own Mac.

By CoreGuard · Jul 14, 2026 · 17 min read

How much SSD writing is normal on a Mac?

There is no universal safe number of SSD writes per day for a Mac. A useful answer needs three readings together: the short-term write rate, that Mac’s own workload baseline, and the long-term slope of NVMe Percentage Used.

That is less satisfying than “under X GB/day is fine.” It is also the only answer I trust. A Mac restoring a backup, importing a photo library, installing Xcode, or exporting video can write heavily for a good reason. An otherwise unchanged Mac can also sit at a modest-looking rate for days because one process has developed a retry loop. The first is a burst. The second may be an anomaly. A daily total alone erases the difference.

I am going to show the complete manual method, including the counter math. No paid app or CoreGuard install is required — it uses Activity Monitor and the free, open-source smartmontools. The point is not to turn one more system number into a source of anxiety; it is to stop asking a rate to answer a question it cannot answer.

GB per day is an observation, not a verdict

“Mac writing 100 GB per day” sounds dramatic. Spread evenly across 24 hours, however, 100 decimal GB/day is only about 1.16 MB/s. The same 100 GB written during a 15-minute import averages about 111 MB/s and then stops. Same daily total. Completely different shape.

This is why I will not publish a table that labels 20 GB/day green, 100 amber, and 500 red. It would look useful and be technically dishonest.

A video editor, a developer building large projects and containers, and a lightly used email Mac do not share a meaningful normal. Neither do a restore day and an idle Sunday on the same machine. SNIA’s endurance guide explicitly treats workload — random versus sequential writes, block size, free space, and overprovisioning — as part of the endurance problem, and it distinguishes host writes from NAND writes. The workload matters, not just the byte total. (SNIA, “Endurance of NVMe, SAS, and SATA SSDs”)

There is another missing number. Apple’s published Mac specifications list SSD capacities but do not provide a consumer, model-specific rated-TBW figure that I can plug into a warranty equation. Apple’s MacBook Pro technical specifications are representative: capacity is specified; rated write endurance is not. Taking the TBW rating from a retail Samsung or Crucial drive and pasting it onto Apple’s soldered storage is not a conservative estimate — it is a different product, controller, NAND configuration, firmware, workload definition, and warranty.

People also use “TBW” to mean two different things. One is the actual lifetime host-write total, expressed in terabytes. The other is a manufacturer’s rated TBW endurance. Your Mac can expose the first without Apple publishing the second. Keep those two meanings separate, or the arithmetic will manufacture certainty the data never contained.

Read one: the short-term write rate

Rate answers one narrow question: how fast are host writes accumulating during this window? It is the right view for a restore, import, build, export, indexing run, or suspected loop.

Apple says Activity Monitor’s Disk view tracks disk reads and writes and shows how much data is read or written. Open Activity Monitor → Disk, choose View → All Processes if necessary, and sort by Bytes Written. (Apple Activity Monitor User Guide) That immediately gives you suspects, not convictions.

Take two readings, not one. Record the process name and its Bytes Written value, wait through a known interval, then record it again. Divide the byte delta by elapsed time. A process showing 80 GB accumulated is not necessarily writing now; a process that adds 8 GB during a ten-minute idle window is telling you something current.

Activity Monitor is process accounting at the operating-system layer. The NVMe lifetime counter is device accounting at the controller layer. They will not reconcile byte-for-byte: caches, delayed writes, filesystem work, kernel attribution, process exits, and the measurement window all get between them. Do not add every Activity Monitor row and call the result NAND wear. Use Activity Monitor to ask who is active now.

For a whole-drive rate, compare two NVMe Data Units Written readings instead. Because each reading is rounded up to a 512,000-byte unit, the result is approximate at that resolution — fine over hours or days, noisy over seconds. The decimal-GB formula is:

host GB/day = change in Data Units Written × 512,000
              ÷ 1,000,000,000 ÷ elapsed days

That rate is still a host-write rate. It is not a pass/fail score, and it is not physical flash traffic.

Read two: this Mac’s workload baseline

A baseline answers the question the internet cannot: is this rate unusual for this Mac doing this kind of work?

Do not build the baseline from one quiet hour. Keep several comparable windows and label them honestly: ordinary workday, overnight idle, photo import, video export, macOS update, large build, backup restore. A week is a practical starting sample, not a law. What matters is seeing repetition and context.

Your baseline should have more than one lane. An idle baseline helps catch background behavior. A working baseline tells you what your normal tools cost. A known-heavy lane stops a legitimate export from being mislabelled simply because it is large.

Howard Oakley provides a useful attributed example precisely because it is not a rule. In 2026 he reported that his own 1 TB iMac Pro had written about 150 TB across more than seven years, averaging about 21 TB/year, or just under 60 GB/day. (Howard Oakley, “How long will my Mac’s SSD last?”) That is one production Mac, with his workload and his uptime. It does not make 60 GB/day safe, unsafe, high, or low on yours.

This is also the honest answer to “Is 100 GB/day safe on a Mac SSD?” Maybe it is an ordinary plateau for a media workstation. Maybe it is a one-day restore burst. Maybe it is ten times the unchanged baseline of a Mac that was meant to be idle. Until you know which, 100 GB is just a numerator attached to a day.

Burst, plateau, or sustained anomaly?

The useful taxonomy is about shape and context, not a magic y-axis value.

The end condition matters. Spotlight indexing after an update can be a burst even if it lasts longer than you expected. If the same rate continues after indexing should have settled, the pattern has changed from “busy” to “unexplained.” That is when you identify the writer and investigate. Do not disable a macOS service merely because its total is large; first show that its rate is persistent and inconsistent with the work being done.

A plateau is not automatically safer than a burst. It is simply easier to explain when it tracks a workload. A burst is not automatically harmless either; repeated bursts with no corresponding event may form their own anomaly. The labels are hypotheses you can test against time and behavior.

This is the point people skip when they ask whether high TBW is normal on a MacBook. A lifetime total has no shape. You need the recent slope, the machine’s age and power-on history, the workload that produced it, and the drive’s own wear estimate. “High” without those is decoration.

What Data Units Written actually counts

NVMe gives us a well-defined host counter. The NVM Express Base Specification says Data Units Written is the number of 512-byte data units the host has written to the controller, reported in thousands and rounded up. One raw unit therefore means 1,000×512 bytes, or 512,000 bytes — not 512 bytes. (NVM Express Base Specification, SMART / Health Information Log)

That missing “thousands” is a brutal little footnote. Multiply a raw Data Units Written value by only 512 and you undercount by 1,000×.

I ran smartmontools 7.5 against the internal NVMe device on the Apple-Silicon Mac used to build CoreGuard. The relevant lines were:

$ smartctl -a disk0
Data Units Written:                 66,712,577 [34.1 TB]
Percentage Used:                    2%
Power On Hours:                     1,421
Available Spare:                    100%
Available Spare Threshold:          99%

The raw conversion is explicit:

66,712,577 × 1,000 × 512 bytes
= 34,156,839,424,000 bytes
≈ 34.1 TB

Using only 512 would produce about 34.2 GB — wrong by three orders of magnitude.

Two cautions matter more than the big number. First, Data Units Written is host traffic, not physical NAND traffic. SNIA defines the write-amplification factor as NAND writes divided by host writes. The NVMe counter gives you the denominator; controller garbage collection, wear-levelling, and other internal work are not exposed in this number. You cannot reverse-engineer physical cell writes without controller data Apple does not provide.

Second, 34.1 TB written alongside 2% Percentage Used does not reveal the drive’s rated endurance. It is tempting to divide 34.1 TB by 0.02 and announce a 1.7 PB lifetime. Do not. Percentage Used is a vendor-specific estimate, reported in whole percentage points, and the standard does not promise a linear mapping from host TB to that estimate. Apple supplies no consumer model-specific rated-TBW number to validate the extrapolation.

You can perform another tempting calculation: 34.1 TB divided by 1,421 power-on hours is about 576 GB per powered-on day. That arithmetic describes this counter’s whole history — every heavy workload since the Mac was new, folded together. It is not a calendar-day baseline, and definitely not a safe/unsafe verdict. The Mac’s own NVMe log still reports 2% used. The honest conclusion is that the counters need context, not that either number is lying.

Available Spare is separate again. Here it is 100%, with a threshold of 99%. That does not mean the SSD is “99% healthy,” nor does it turn Percentage Used into 98% remaining. The NVMe specification defines Available Spare as a normalized percentage of remaining spare capacity, and its threshold as the percentage below which a warning may occur. Report the fields separately; do not combine them into a homemade health score.

The Apple-Silicon access detail is worth stating plainly. On this Mac, smartmontools 7.5 reads the internal Apple NVMe health log natively — its Darwin implementation uses an IONVMeSMARTInterface to fetch NVMe identify data and log pages, and its own macOS example is smartctl -a disk0. (smartmontools Darwin NVMe source) Old blanket advice that internal SSD SMART is always unavailable on Apple Silicon is outdated. That is not a promise that every Mac, macOS release, or external enclosure behaves identically, and health-log access is not the same as support for an NVMe self-test. The precise claim is narrower and stronger: smartctl 7.5 natively returned these internal health fields on the measured Apple-Silicon Mac.

Read three: the long-term Percentage Used slope

The third reading is deliberately slow. Percentage Used asks whether the controller’s own endurance estimate is moving over the long term.

The NVM Express Base Specification defines it as a vendor-specific estimate based on actual use and the manufacturer’s prediction of NVM life. A value of 100 means the estimated endurance has been consumed but may not mean the subsystem has failed; the value is allowed to exceed 100. That is why I refuse to describe it as a countdown.

One reading — 2%, 12%, even 80% — is a state, not a trajectory. Record it with a date, then compare it over months. Because the field is a whole percentage and vendor-derived, a flat value over a short interval may simply mean the counter has not crossed its next displayed step. A single one-point change is not enough to justify a precise “years left” line either.

What matters is whether the slope changes. If Data Units Written is accumulating at the familiar baseline and Percentage Used moves slowly at its familiar pace, that is internally consistent. If the short-term rate jumps, the baseline comparison says the workload did not change, and the longer wear slope later steepens, all three readings point in the same direction: something changed and deserves attribution.

Even then, you have not predicted a failure date. SSDs can fail for reasons unrelated to exhausted write endurance, and a vendor wear estimate does not know tomorrow’s workload. The slope is evidence for cautious planning, not an appointment with a dead drive.

What these numbers cannot tell you

Keep the boundary sharp:

• Data Units Written cannot reveal physical NAND writes. It is the host counter; controller write amplification is hidden.
• Actual host TB written cannot reveal Apple’s rated TBW. Apple does not publish the consumer model-specific figure needed for that comparison.
• Percentage Used cannot give a precise remaining lifetime. It is vendor-specific, coarse, and allowed to pass 100.
• Power-On Hours is not calendar age. Dividing by it produces a powered-hour average, not a normal day for the owner.
• A drive counter cannot name the writer. Use process-level observation and workload correlation for attribution.
• An anomaly is not a danger verdict. Updates, imports, restores, builds, sync, and exports can all write legitimately.

Also keep write endurance separate from current data safety. A low Percentage Used value does not cancel media errors, critical warnings, a falling Available Spare value, corruption, or a bad backup situation. Conversely, a high daily write total by itself does not prove any of those conditions exist. If you want the failure-and-backup side of the story, that’s our companion piece on what SMART can and can’t tell you.

How to read your Mac’s SSD writes

The whole method, free and repeatable — in order:

1. Choose a window and write down the workload. Note the start time and what the Mac is doing: idle, ordinary work, update, restore, import, build, export, VM, or sync. Without this note, the number will lose its meaning by tomorrow.
2. Use Activity Monitor for live attribution. Open Applications → Utilities → Activity Monitor → Disk, show all processes, and sort by Bytes Written. Record the leading process names and byte values twice during the same window; the delta tells you who is adding writes now. Treat a kernel or aggregate process name as an accounting endpoint until you correlate it with an app or action.
3. Install a current smartctl and identify the internal disk. Homebrew currently packages smartmontools 7.5.

   brew install smartmontools
   diskutil list internal physical
   smartctl --version
   smartctl -a disk0

   On the measured Apple-Silicon Mac the internal physical device is disk0 and no third-party kernel extension is involved. If diskutil shows a different identifier, substitute it. If smartctl reports a permission error, rerun only the read command with sudo.
4. Save the raw fields, not a screenshot of a verdict. Record the timestamp, Data Units Written, Percentage Used, Power-On Hours, Available Spare, and Available Spare Threshold. smartctl prints the human-readable TB value in brackets, but keep the raw Data Units Written count so you can calculate the delta at the counter’s 512,000-byte resolution. Each reading is rounded up to a whole unit, so a short-interval delta is approximate to within one unit — the longer the interval, the smaller that rounding matters.
5. Take a second reading after a useful interval. For a suspected live event, compare over minutes or hours. For normal writes per day, compare the same kinds of days across a week or longer. Calculate host GB/day as change in Data Units Written × 512,000 ÷ 1,000,000,000 ÷ elapsed days.
6. Build separate baselines. Keep ordinary-work, idle, and known-heavy windows apart. Look for a burst that ends, a plateau attached to real work, or a sustained rate that persists after the workload is unchanged or finished.
7. Compare Percentage Used over a much longer interval. Date every reading and look for its slope over months, not hours. Do not turn two whole-number percentages into an exact failure date. Check whether a changed wear slope agrees with the recent host-write rate and baseline evidence.
8. Attribute before changing anything. If the rate is persistently abnormal, return to Activity Monitor, name the process, and correlate it with logs, updates, active jobs, or reproducible app behavior. A large counter is not, by itself, a reason to disable Spotlight, remove a cache, or blame whichever process happens to be at the top after a reboot.

That is the whole manual method. It is free, repeatable, and better than a magic number because it preserves the one thing a threshold discards: what the Mac was actually doing.

Where CoreGuard fits

The manual method works. Its weakness is not access to a secret number; it is memory. Activity Monitor is useful while you are looking, smartctl gives you a device snapshot, and a spreadsheet can preserve the readings — if you remember to take them and label the workload.

CoreGuard automates that observation without changing the system it observes. In the Free tier, the abnormal-write warning is free, it names the process responsible, and basic SSD health and danger warnings stay free. You don’t pay to learn that a process’s write behavior has become abnormal.

Pro adds the detailed per-app write timeline, longer history, and export, plus the endurance detail: lifetime host TB written, power-on hours, raw SMART fields, and a wear trend with a “years left” projection. That projection is a trend estimate, not a failure date; it inherits the uncertainty of Percentage Used, future workload, and the hardware’s own reporting.

CoreGuard observes. It never throttles, blocks, or modifies a writer, and it does not claim to change SSD endurance. The value is the joined timeline — rate, named process, that Mac’s baseline, and the long-term wear slope in one place. The warning is free; Pro is for the detailed history and portable evidence, not for access to danger. CoreGuard isn’t out yet — if that’s the read you want, get notified and grab it free at launch, or see what Pro adds.

Frequently asked questions