If you have ever browsed the root of a Mac volume with hidden files visible, you will have seen a folder called .fseventsd sitting there, owned by the system, containing files you cannot easily open. It is not clutter and it is not something an app forgot to clean up. It is the File System Events log, a low-level journal that macOS keeps on every mounted volume to record the fact that something changed, without recording what. Several core system services depend on it running continuously, and understanding what it does explains both why it exists and why you should not go looking for ways to delete it.
What the File System Events log actually records
The FSEvents API is a kernel-level mechanism that watches a volume for changes — files created, modified, renamed, or deleted — and writes a lightweight stream of notifications describing where something changed, not what changed or what the file now contains. Think of it as a change log rather than a content log: an entry says "something happened inside this directory," and it is up to whichever process reads the log to go and look at what is actually different.
This is fundamentally more efficient than the alternative, which would be periodically re-scanning an entire volume to notice what is different. Instead, any process that cares about filesystem changes can simply watch the events stream and react only when something relevant appears.
Which services actually consume this stream
Spotlight is the most active consumer. Rather than re-indexing your entire drive from scratch whenever a file changes, Spotlight's indexing service watches the FSEvents stream and does incremental reindexing — it only looks at the specific files and folders that were flagged as changed, which is why Spotlight results usually reflect a newly saved file within seconds rather than after a full rescan.
Time Machine relies on the same mechanism for a similar reason. To back up efficiently, it needs to know which files changed since the last backup without walking the entire disk each time. The FSEvents log gives it a fast way to identify the relevant subset of changed paths, which is a large part of why incremental Time Machine backups after the first one are comparatively quick.
Beyond these two, various third-party applications that need to react to filesystem changes — sync tools, backup utilities, developer tools that watch a project folder for edits — use the same FSEvents API, and by extension depend on .fseventsd being present and healthy on the volumes they watch.
Every volume gets its own, tagged with a UUID
.fseventsd is per-volume, not global. Each mounted volume that supports it — your internal drive, an external drive, a disk image — maintains its own separate events log at the root of that volume. Inside, the log is tagged with a UUID unique to that volume, which is how the system tells apart the event history of one disk from another, particularly useful when volumes get unmounted, remounted, or moved between machines.
This per-volume design also explains why deleting or reformatting one volume does not affect the FSEvents history of any other: they are entirely independent journals, even on the same physical machine.
Why it can grow on high-churn volumes
Because every meaningful filesystem change generates an entry, a volume with a very high rate of file creation and modification — a build server's output directory, a busy Time Machine backup destination, a disk hosting active development work with rapid file churn — can accumulate a comparatively larger .fseventsd than a mostly static volume like an archive drive. This is expected behaviour rather than a leak: it is a log growing in proportion to actual activity on that volume.
In most everyday use on a personal Mac, this folder stays small relative to everything else on the disk. It is worth knowing about mainly so that, if you do notice it while browsing hidden system folders, you recognise it as ordinary rather than mysterious.
What happens if it is missing or corrupted
macOS treats .fseventsd as disposable infrastructure rather than as precious data. If the folder is missing — because a volume was formatted without it, or because it was somehow deleted — or if the log inside it becomes corrupted, macOS simply rebuilds it. The system notices the log is absent or unreadable and starts a fresh one, and consumers like Spotlight fall back to doing a fuller scan of the affected volume to catch up on whatever they might have missed.
This is why you will not find official guidance suggesting you back up or protect .fseventsd. It is not a record of your data, only a record that data changed, and losing it costs you nothing more than a temporary slowdown while the affected services re-establish their bearings on that volume.
Why this matters when you are trying to understand disk usage
None of this makes .fseventsd a meaningful factor in a full-disk-full investigation — it is one of the smaller hidden system folders on most volumes, dwarfed by things like Xcode's DerivedData, browser caches, or a Docker virtual disk. But when you are auditing a volume with hidden files shown, knowing what .fseventsd is means you can rule it out immediately instead of wondering whether it is safe to touch. It is infrastructure the operating system maintains for itself, not a folder a user is expected to manage.
Conclusion
.fseventsd is one of several unglamorous folders macOS keeps running quietly in the background so that more visible features — instant Spotlight results, fast incremental backups — work the way you expect. It costs a small, activity-proportional amount of space, rebuilds itself without drama if it ever goes missing, and is not something you need to think about unless you are curious what it is.
That kind of curiosity is exactly what we designed VolumeLens to reward rather than punish: when you scan a volume, hidden system folders like this one are shown honestly rather than hidden from you or mislabelled, so you can see what a drive actually contains and decide for yourself what is worth your attention.