Time Machine Local Snapshots: Why 'System Data' Balloons Overnight

You free up 40 GB, check Storage settings the next morning, and “System Data” has quietly grown back by 20 GB overnight with no obvious cause. This is almost always Time Machine local snapshots, and most people have no idea the feature exists — it works entirely without a backup drive connected.

What a local snapshot actually is

Since macOS Sierra, Time Machine takes hourly APFS snapshots of your internal disk even when no Time Machine backup drive is plugged in. The idea is that if your Time Capsule or external drive is disconnected — the normal state for a laptop — you still have hourly restore points until the drive reconnects and a real backup happens.

The problem: on a disk that’s changing a lot — you’re compiling, downloading, deleting large files — each snapshot retains deltas of everything that changed since it was taken, and macOS’s automatic thinning doesn’t always keep pace with how fast you’re generating new data. On a developer machine doing heavy build work, snapshots can genuinely consume tens of gigabytes before macOS gets around to purging the oldest ones.

Seeing what’s actually there

tmutil listlocalsnapshots /

This lists every local snapshot by date. If you see a dozen or more spanning the last week, that’s the ballast.

To see the actual disk space involved — this command can take a minute or two to run since it’s walking APFS metadata directly:

tmutil listlocalsnapshotdates /
diskutil apfs list   # shows "Capacity in Use by Snapshots" near the bottom

Clearing them

macOS is supposed to purge local snapshots automatically under disk pressure — but “automatically” here means only once free space drops critically low, which for most people means never until it’s already a problem. You can force it manually:

# Delete a specific snapshot by date (from listlocalsnapshotdates)
tmutil deletelocalsnapshots 2026-08-28-140023

# Or ask macOS to purge as much as it's willing to, immediately
tmutil thinlocalsnapshots / 10000000000 4

The thinlocalsnapshots command’s arguments are a target byte count and an urgency level (1–4, where 4 is most aggressive) — macOS treats this as a request, not a guarantee, and will refuse to thin below whatever minimum it considers safe. In practice this usually reclaims most of what’s available.

Is this safe? Yes, with one caveat: local snapshots are your only restore point if you don’t have an external Time Machine drive connected regularly. If you rely on local snapshots as your actual backup strategy — many people do, without realizing it — clearing them removes your ability to roll back to yesterday. If you have a real, current Time Machine backup on an external drive or network share, local snapshots are pure redundancy and safe to clear freely.

Why this differs from everything else in this series

Every other cache covered across these guides — DerivedData, node_modules, package manager caches — is dead weight the instant it’s created: nobody was ever going to read it as data, only as a performance shortcut. Local snapshots are the one category here that’s genuinely doing something useful (letting you restore a deleted file from three hours ago), which is exactly why macOS doesn’t let you disable the feature outright — you can only ask it to thin more aggressively or delete specific snapshots.

If you want to stop the accumulation at the source rather than clearing it repeatedly, the only lever is connecting an actual Time Machine backup drive periodically — once a real backup completes, local snapshots older than the backup become far more disposable to macOS’s own automatic thinning.

The commands above are free and they work. DevCruft, a free Mac app for developers we’re building, is being designed to show local snapshot space alongside everything else eating your disk, so “System Data” stops being a mystery number and becomes a specific, actionable line item. Join the waitlist to hear when it launches.

For the rest of what hides inside macOS’s System Data category, see the full System Data breakdown.