What are notifyd and distnoted on Mac?

Two notification services, not two alert apps

Apple’s installed manual calls notifyd the server for the notification system described by notify(3). It starts automatically through launchd. The distnoted manual describes distributed notification services and explicitly says users should not run it manually.

These are software messages. A component can notify another component that state has changed without displaying a banner, playing a sound or adding an item to Notification Center. Turning off an app’s visible alerts therefore does not necessarily stop the internal messages associated with its work.

The distinction matters when searching for a fix: a busy notification server is not proof that too many pop-up alerts are enabled. Nor does its name tell you which app posted the messages or whether the underlying activity is faulty.

Why there can be several distnoted processes

On our read-only macOS 27.0.1 check on 23 October 2026, notifyd ran as root at /usr/sbin/notifyd. distnoted ran at /usr/sbin/distnoted under the signed-in user, root and several separate system users.

Separate users and services can have separate processes. Their presence alone is not a duplicate-app problem. Do not terminate all of them simply because the name repeats. The user and executable path help distinguish the entry you are investigating.

Use View › All Processes in Activity Monitor. Search the exact process name, inspect it, and note the user and PID before taking a sample. A new PID after a restart is a different process instance even when the displayed name is unchanged.

What sustained high CPU can mean

Heavy message traffic or repeated work by a client is one possible explanation. The name does not establish a notification loop, a corrupt database or a single offending app. A useful investigation looks for a repeatable relationship with a task, login item or app version.

Check whether the Mac is actually slow, warm or using more power, and whether the busy period continues after the visible task finishes. CPU percentage is a point-in-time view; sort by CPU and watch a meaningful interval rather than treating the largest number once as a diagnosis.

If several processes are busy together, the notification service may be responding to other work. Our slow Mac guide helps separate CPU load from memory pressure, storage and other causes of a sluggish desktop.

Use Sample Process to preserve evidence

1. Select the busy entry. Confirm its PID and user, especially when several distnoted rows are present.
2. Choose Sample Process. In Activity Monitor, use the More menu. Apple says this collects a three-second report of the selected process.
3. Save the report locally. Note the time and the task you were performing. A sample captured while the process is idle may miss the behavior.
4. Compare with the visible workload. Quit one optional app normally after saving work, then observe whether the activity changes. Reopen it later if needed to check whether the pattern is repeatable.
5. Share relevant evidence with support. Use the app developer or Apple’s support route. Review reports before publishing them; they can include identifying paths or process information.

A sample shows where the sampled process spent time. It may expose useful function names, but it does not guarantee that the sender of every notification is identified. Waiting in a system function is not, by itself, evidence that the function is the cause.

Make changes that test a specific theory

Update the app associated with a repeatable trigger and install supported macOS updates. Save work and restart normally if the behavior continues. Record whether it returns before opening your usual apps or only after a particular task.

If it occurs only in your normal login environment, a safe mode comparison can help narrow software loaded at startup. Safe mode changing the behavior does not identify one app automatically; compare the actual startup items and installed software.

Avoid broad preference resets, deletion of notification databases and random launchctl commands. Those can affect unrelated software or data without establishing why the original process was busy. For a managed Mac, ask IT before changing background services.

Should you force quit notifyd or distnoted?

Do not use repeated force quits as a routine fix. These services support other software, and a replacement process may be started automatically. Work can be interrupted while the underlying client continues to trigger the same behavior.

The installed distnoted manual also says it has no configuration options. There is no general user-facing “clean distnoted” maintenance task. If the problem is sustained and reproducible, keep a sample and a clear account of the triggering task.

Where Tend fits

Tend lists processes running as your current user. Your user-owned distnoted can appear individually, because its executable is outside an app bundle. The root notifyd and system-user distnoted copies are not named in that list; their cost can contribute to the macOS share.

Free current app CPU, memory and estimated watts can help you observe the apps around a busy period. They do not trace which app posted an internal notification. Activity Monitor’s all-user view and a process sample provide the more relevant evidence.

Questions

Related guides

Sources

• Apple, installed man notifyd and man distnoted; read-only user/path check on macOS 27.0.1.
• Apple, Activity Monitor diagnostic reports and Sample Process.

Sources checked 23 October 2026. Spotted something out of date? Tell us and we'll fix it.