What is fseventsd on Mac?

What fseventsd does

fseventsd runs as root from /System/Library/Frameworks/CoreServices.framework/.../FSEvents.framework/Versions/A/Support/fseventsd. When anything creates, modifies, renames or deletes a file, the kernel tells fseventsd, which:

• batches the changes per folder
• writes them to a journal in the hidden /.fseventsd folder on each volume
• delivers them to subscribers through the FSEvents API

Subscribers include Spotlight, Time Machine, Finder, iCloud Drive, Dropbox, and every dev tool that watches files for changes.

Why it uses CPU

fseventsd’s load tracks how many files change:

• Package installs: npm install, pnpm install, pip install or cargo build create tens of thousands of files in seconds.
• Git operations: checking out a branch or rebasing a large repo.
• Builds and watchers: rebuilds writing to dist, .next or DerivedData on every save, plus many watchers listening.
• Docker bind mounts: a container writing to a mounted host folder.
• Background writers: a browser cache, a sync client, or an app logging to files in a loop.

How to find who is writing

sudo fs_usage -w -f filesys | grep -E 'WrData|create|rename|unlink' | awk '{print $NF}' | sed -E 's/\.[0-9]+$//' | sort | uniq -c | sort -rn | head

The last column of fs_usage is the process name (with a thread ID, stripped here); the top counts are your heavy writers. Stop with Ctrl-C after a few seconds. To see which paths one process is writing:

sudo fs_usage -w -f filesys node | head -40

How to make it calm down

1. Stop forgotten dev servers and watchers. Several old vite or next dev instances watching the same tree multiply the work. See orphaned node processes.
2. Point build output and caches outside folders you sync (iCloud Drive, Dropbox).
3. Exclude dev folders from Spotlight and Time Machine. That doesn’t stop fseventsd recording changes, but cuts the downstream work those events trigger.
4. For Docker, prefer named volumes over bind mounts for databases and node_modules.
5. Restart if fseventsd stays high with nothing writing; a corrupt journal on an external disk can do that.

When to worry

fseventsd is protected by System Integrity Protection, so there’s no realistic impostor. Confirm the path with ps -o user,command -p $(pgrep -x fseventsd). Worry instead about an unknown process that shows up at the top of fs_usage writing constantly, especially one running from your home folder: check it with codesign -dv --verbose=2 <path>.

Seeing it in Stat Space

Stat Space’s Disk tab shows top apps by I/O, which usually points straight at the writer behind fseventsd’s load. Its orphan sweep finds dev processes like node, vite and tsc still running after their terminal or agent closed, which are a common source of watchers nobody is using.