Something is using all your bandwidth. Activity Monitor has a Network tab, you open it, and it shows cumulative bytes since each process started, which tells you what has used the most traffic this week rather than what is using it this second.
Why the built-in view misleads
Cumulative counters are the wrong instrument for a live problem. A backup agent that moved 40 GB last Tuesday will sit at the top of the list forever, while the process actually saturating your uplink right now shows a small number because it started ten minutes ago. Sorting by total sent is close to useless during an active slowdown.
The built-in tool that does give you a rate is nettop:
nettop -P -L 1The -P flag aggregates per process rather than per connection, and -L 1 prints one sample and exits. Without -L it runs interactively and refreshes in place.
The usual suspects
- nsurlsessiond, which is iCloud sync. Large uploads after a photo import can run for hours.
- softwareupdated and mobileassetd, downloading macOS updates in the background before you have agreed to install anything.
- backupd, if a network Time Machine destination is mounted.
- Browser helper processes, which appear under generic names and need the parent tab to be identified.
- Container runtimes pulling images, which show up under the runtime rather than the thing that requested the pull.
Correlating rate with everything else
A network spike on its own is rarely the whole story. The useful question is what else was happening at the same moment: whether CPU spiked with it, whether the disk was being written, whether it started when you plugged in a drive.
Burrow's Network tool shows live throughput per interface and per process, so the process saturating the link is the one at the top right now rather than the one with the largest lifetime total. Because Status samples land in a local history, you can also go back and see what a spike from last night coincided with, which is the part no live view can give you.