What is timed on macOS, and why is it using the network?

Last updated: 2026-07-31

What it is

timed is Apple’s system time synchronization daemon. The timed(8) manual describes it as the service that keeps the system clock accurate using reference clocks such as NTP servers. It also estimates how uncertain the current time is, rather than treating every clock reading as perfectly exact.

The normal Apple component runs from /usr/libexec/timed, carries the code-signing identifier com.apple.timed, and is started by launchd under the dedicated _timed user. It is not Time Machine, despite the similar-looking name, and it is not a background application installed by the user.

Accurate time matters beyond the clock in the menu bar. macOS uses the system clock when assigning timestamps to files, email, and messages. Certificates and many authentication mechanisms also depend on dates and time windows. A small clock difference does not automatically break every connection, but a sufficiently large error can cause certificate-validity checks, authentication, and other time-dependent services to fail.

Why it talks to the network

When “Set time and date automatically” is enabled, timed needs an external reference for the correct time. It queries the network time server configured on the Mac when synchronization is needed or when an earlier attempt must be retried. Apple lists time.apple.com and time-macos.apple.com among its macOS time services. These services use NTP over UDP port 123.

Those Apple servers are not the only possible destinations. A user or administrator can configure another NTP server, and a managed Mac may use an organization’s own time service. Seeing a different configured NTP destination therefore does not, by itself, mean that timed has been replaced or compromised.

A check may be triggered after startup, wake, or restoration of network access. Apple has not published a stable packet-by-packet schedule, so these triggers should not be read as promises that a request always happens at a particular moment. An inspected system configuration includes RunAtLoad, KeepAlive, and a 3,600-second StartInterval. Those values describe how launchd schedules the service; they do not prove that timed makes one network request every hour. Internal decisions, retries, sleep, wake, and network availability can change the observable pattern.

How much traffic is normal

There is no reliable universal byte allowance for timed. Apple does not publish a verified number of bytes per synchronization or per day, and the exact effect of retries and differences between macOS releases has not been independently established. A precise daily total would therefore be misleading.

When the Mac is offline, or when automatic date and time is disabled, there can be no synchronization traffic. During ordinary connected use, the expected pattern is intermittent, short NTP packets rather than a continuous transfer. The total is normally far below what is required to load an ordinary web page.

Frequency alone also needs context. Several requests around startup, waking, reconnection, or a retry do not establish a permanent fixed interval. Likewise, seeing the process remain present while its network traffic is zero is normal: launchd can keep the service running even when no synchronization request is currently needed.

Can you turn it off

For normal use, keep automatic time enabled. timed provides a system-level integrity function while generating very little ordinary traffic, so disabling it is not a useful general-purpose bandwidth or performance optimization.

If you need to stop automatic network time calibration, use:

Apple menu  > System Settings > General > Date & Time > Set time and date automatically

Turn that setting off. On older macOS releases, the name or location of the setting may differ.

Afterward, the Mac will no longer correct its date and time automatically over the network. You must maintain the clock manually. As the clock drifts, timestamps on files, email, and messages can become inaccurate. A larger error may also cause failures in certificate-validity checks, authentication, and other services that require dependable time.

Turning off the setting does not guarantee that the timed process disappears. It is a system daemon managed with KeepAlive, so launchd may continue to run it or restart it after it is terminated. Ending the process in Activity Monitor is therefore not equivalent to disabling automatic synchronization, and trying to remove the system component is not the supported control.

What people get wrong

• “timed connects exactly every 15 minutes.” There is no reliable basis for this claim. Apple has not published a fixed network-request period. A current inspected configuration contains a 3,600-second service interval, but that is launchd scheduling information, not proof of hourly NTP traffic. Retries, internal scheduling, waking, and network state can all affect actual requests.

• “If timed appears in Activity Monitor, the Mac is infected or being monitored.” The instance at /usr/libexec/timed with Apple’s com.apple.timed signing identifier is part of macOS. The name alone is not enough to authenticate an unrelated file, however; a third-party executable called timed does not become trusted merely by copying the system process name.

• “Disabling timed will noticeably save data or make the Mac faster.” Normal time synchronization uses very small, brief NTP exchanges. It is not ordinarily a meaningful bandwidth target, while losing dependable time can cause much more disruptive timestamp, certificate, authentication, and connectivity problems.

• “Force-quitting or uninstalling timed turns off automatic time.” The service is configured with KeepAlive, so launchd can start it again after it exits. The supported user-facing control is “Set time and date automatically” in Date & Time settings. Turning off that option still does not promise that the daemon process itself will exit.

• “timed mainly synchronizes with other Macs on the local network.” The default configuration points to Apple’s network time services. Administrators can replace that destination with an organization’s NTP server, but local Mac-to-Mac synchronization is not the service’s primary default role.

• “Even a tiny clock error will break every network connection.” That overstates the risk. A sufficiently large date or time difference can make certificates appear not yet valid or already expired and can interfere with time-dependent authentication. The actual result depends on the size of the error and the protocol involved; a slight deviation does not guarantee a complete loss of connectivity.

Seeing what it actually used

If you need an observed total instead of a general estimate, use Bytetally’s per-process statistics and inspect timed over the period you are investigating. Compare the traffic around startup, wake, and network restoration rather than assuming a fixed request schedule. This shows whether you are seeing brief synchronization activity or a sustained pattern that needs closer examination.

Related processes

Common questions