Why is SubmitDiagInfo using the network on my Mac?

Last updated: 2026-07-31

What it is

SubmitDiagInfo is a background system process included with macOS and signed by Apple. Its executable is located at /System/Library/CoreServices/SubmitDiagInfo, while com.apple.SubmitDiagInfo is both its code-signing identifier and its launchd label. Calling that identifier an app bundle ID is not strictly precise because the executable does not have an attached Info.plist.

The process handles diagnostic, crash, system-event, and usage reports that qualify for submission and have not yet been sent. It does more than transmit data: it also checks and queues reports, and removes diagnostic information that was generated more than a month ago and is no longer needed.

For that reason, seeing SubmitDiagInfo in Activity Monitor does not by itself mean your Mac is uploading anything. The process can be active while examining a queue or performing local cleanup, even when there is no network transfer underway.

Why it talks to the network

SubmitDiagInfo can contact Apple's diagnostic and analytics receiving services when Share Mac Analytics is enabled and eligible reports are waiting to be sent. Automatic sharing requires user consent.

Apple specifically lists several events that can lead to information being sent automatically: an app quitting unexpectedly, the user force-quitting an app, and a system error that causes or requires the Mac to restart. Other system events and usage information covered by the sharing permission may also be submitted.

Reports are not necessarily transmitted when they are created. If the Mac is offline, they can remain queued and be sent after an internet connection becomes available again. Related analytics information may also be sent when the user actively chooses to report a problem.

If Share with App Developers is enabled separately, Apple may provide developers with a relevant subset of non-personally identifying analytics data. There is no evidence that SubmitDiagInfo itself connects directly to third-party servers. The exact list of hosts used at runtime has not been verified, and URL strings found inside the executable do not establish which endpoint a current submission actually uses.

How much traffic is normal

Normal traffic can range from zero to a short batch of uploads after one or more reportable events. Zero is expected when analytics sharing has not been authorized or when there are no reports waiting to be sent.

Apple has not published a reliable typical byte range or a maximum size for SubmitDiagInfo traffic. There is therefore no supported MB figure that can be used as a universal threshold. The amount depends on how many reports are pending and what those reports contain.

Its documented pattern is closer to occasional log submission than to a continuous audio, video, or cloud-storage stream. A burst after a crash, forced app exit, system error, period without connectivity, or manual problem report can fit that pattern. Periodic appearances of the process do not establish periodic uploads, because actual transmission still depends on consent, a pending report, and network availability.

Can you turn it off

Yes—but the supported control is for analytics sharing, not for deleting or forcibly disabling the system process.

Go to Apple menu > System Settings > Privacy & Security > Analytics & Improvements, then turn off Share Mac Analytics. If you also do not want Apple to share the relevant analytics subset with app developers, turn off Share with App Developers as well.

After Share Mac Analytics is disabled, the Mac stops automatically providing Apple with its crash, diagnostic, system-event, and usage analytics. Those reports consequently no longer contribute data to the related Apple quality-improvement work.

This setting does not prevent macOS from generating or displaying diagnostic reports locally. They can still be viewed under Mac Analytics Data in Console. It also does not guarantee that SubmitDiagInfo will never run again, because local report cleanup remains one of its responsibilities. A later decision to submit a problem report manually is a separate, explicit action.

A universal initial default for the sharing setting on modern macOS has not been verified. The actual state may reflect choices made during initial setup or a device-management policy, so it is better to inspect the current setting than to assume it is on or off.

What people get wrong

• “SubmitDiagInfo is malware or a third-party telemetry program.” Its Apple code signature, system location, and launchd label identify it as an Apple macOS component.

• “If the process appears, my Mac must be secretly uploading.” Process activity is not proof of network activity. SubmitDiagInfo also checks, queues, and cleans up reports, while automatic analytics submission requires consent.

• “It continuously uses the network and uploads all my files or browsing activity.” There is no evidence for that claim. Apple describes eligible crash, diagnostic, system-event, usage, and hardware or software specification information—not arbitrary user files. Reports can still contain device and software-environment metadata, however, so “not personal files” should not be mistaken for “no privacy-relevant information at all.”

• “Turning sharing off stops diagnostic reports from being created.” It does not. Apple says diagnostic information remains available in Console under Mac Analytics Data even when automatic sending has not been selected.

• “Deleting the system file or permanently blocking it with a firewall will optimize the Mac.” Apple already provides an official analytics-sharing control, and automatic submission does not occur without consent. Removing or forcibly disabling the process is unnecessary and may interfere with its responsibility for cleaning up old reports.

• “Periodic execution means it is continuously online.” A periodically launched process is not the same thing as a continuous transfer. An upload still depends on the sharing setting, eligible queued reports, and an available connection.

Seeing what it actually used

The next step is to check measured per-process traffic instead of inferring it from Activity Monitor presence alone. In Bytetally, look up SubmitDiagInfo in the per-process statistics and compare its actual usage with the times when crashes, restarts, reconnection, or manual reporting occurred. That shows whether it transferred nothing, produced a short batch, or followed a pattern that deserves closer examination.

Related processes

Common questions