What is fseventsd on Mac? File events and high CPU

What fseventsd does

File changes matter to more than the app making them. Software may need to notice that a project folder has changed since it was last opened, or decide which parts of a large tree to inspect again. Apple's FSEvents programming guide describes this change-notification mechanism, including its use by backup applications.

The daemon is infrastructure, rather than an editor, cloud-storage account or collection of your documents. It does not become the owner of every file operation just because its process name appears during disk activity.

On the documentation Mac, a read-only inspection of Apple's installed launch configuration on 30 October 2026 identified com.apple.fseventsd, its com.apple.FSEvents service and this executable:

/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/FSEvents.framework/Versions/A/Support/fseventsd

That establishes the installed service's name and location. It was not a CPU experiment, an inspection of anyone's files or a test across macOS versions. A familiar process name by itself is not an identity check for an arbitrary executable.

Start with the file work already happening

Before changing anything, look at Finder copies, an import's progress and the status of any app deliberately moving files. Note whether the Mac is also updating software or performing a backup. These are observations to compare with the symptom, not a list of proven causes of every fseventsd spike.

Apple does not publish a universal normal CPU percentage or completion time for this daemon in the cited documentation. A brief burst while you carry out work and sustained activity that continues during an otherwise quiet session deserve different descriptions.

Observe it in Activity Monitor

Open Finder › Applications › Utilities › Activity Monitor. Choose View › All Processes, search for fseventsd and use the CPU view to observe whether it stays busy. fseventsd runs as root, not in your account; Activity Monitor's User column shows this.

Then look at the Disk view alongside the progress indicators you already identified. Apple's disk-activity documentation distinguishes the information shown there. Use it to add context; it does not turn fseventsd into an exact list of the applications responsible for its event stream.

Write down the task, time, affected drive and whether the symptom continues after the task completes. Keeping those variables together is more useful than collecting an isolated screenshot of a large percentage. You do not need to terminate a service to observe it.

Narrow the trigger without resetting the service

Save your work and pause an optional task through its own app controls. If the symptom is repeatable, compare the same app action with and without one optional sync client or external device. Keep necessary backup work and file transfers intact until they can be stopped normally.

Change one thing at a time. If closing a cloud app changes the pattern, that is a lead about that setup, rather than proof that iCloud or every sync client is broken. Use the cloud-sync guide for actual sync status and provider controls.

A restart after saving work can establish whether the activity returns in a fresh session. If it returns with one installed app, update that app and provide its maker with a reproducible case. On a managed Mac, give the same details to IT before changing required background software.

Event history is not a cleanup target

Apple's archived technology overview describes an event daemon and persistent change history. That history serves software that needs to learn about earlier changes; it is not a duplicate copy of your documents.

The API guide warns developers against casually purging historical events because other consumers may need them. It also treats the event list as advisory: applications can need another scan rather than assuming it is a perfect audit trail.

Do not use a hidden .fseventsd folder, an event database or a launch configuration as a general cleanup target. Deleting managed history or repeatedly killing the daemon does not establish why it was busy. It can also change the evidence before you understand the original problem.

These developer documents are archived descriptions of the API, last updated in 2012. They explain the role and its limits; they are not a current consumer support bulletin attributing high CPU to a particular app or promising a reset-based fix.

When to investigate the disk instead

If file operations fail, a drive repeatedly disconnects or Disk Utility reports an error, address that concrete symptom. Back up readable important files before repair attempts and follow the First Aid guide. A busy event service alone is not a disk-failure diagnosis.

If your concern is available space, use Storage settings and files you recognize. Event-history removal should not replace finding an actual large library, download or backup destination.

Where Tend fits

Tend helps you look after your Mac; its optional companion shows how it's doing. Tend's free app view shows estimated watts, CPU and memory for the processes in your own account, with 24 hours of energy history; Pro adds 7- and 30-day views.

fseventsd runs as root, and Tend reads only your own processes, so fseventsd isn't in Tend's list. Use Activity Monitor's All Processes view for it. Tend doesn't reset the event service.

Questions

Related guides

Sources

Sources checked 30 October 2026. Menu instructions were checked against Apple's documentation; we ran no CPU test for this guide.

• Apple: FSEvents introduction (archived)
• Apple: FSEvents technology overview (archived)
• Apple: Using the FSEvents API (archived)
• Apple: View disk activity in Activity Monitor
• Apple, installed /System/Library/LaunchDaemons/com.apple.fseventsd.plist, inspected read-only on macOS 27.0.1 on 30 October 2026. This records the service and executable configuration, not a CPU test.

Spotted something out of date? Tell us and we'll fix it.