The symptom is familiar. Video calls stutter. Pages take a beat too long. You have nothing obviously running, and yet the upload direction is clearly busy. If you are tethered to a phone, the allowance is quietly draining while you try to work out what is happening.
Background uploads are almost never mysterious once you look. They are one of a small number of things, and the difficulty is not diagnosis - it is that macOS does not surface the answer anywhere obvious.
The usual suspects
Before reaching for tools, it is worth knowing what you are probably looking for. In roughly descending order of likelihood:
- Photo library sync. iCloud Photos, Google Photos, or Amazon Photos catching up after you imported from a camera. This is by far the most common cause of a sustained multi-gigabyte upload.
- Cloud backup. Backblaze, Arq, or similar doing an initial pass or a large incremental one. Designed to use whatever bandwidth is available.
- File sync clients. Dropbox, Google Drive, OneDrive, Sync. A single large file dropped into a synced folder produces exactly this pattern.
- Time Machine to a network destination. Easy to forget about because it is a system feature rather than an app you opened.
- Development tooling. Container image pushes, CI agents, and simulator downloads that run long after you stopped paying attention.
- Crash and analytics reporting. Small individually, occasionally not small after an app has been crashing all week.
Notice that almost everything on that list is something you asked for at some point. The problem is timing, not intent - these tools have no idea you are on a hotspot in an airport.
What Activity Monitor can and cannot tell you
Activity Monitor's Network tab is the obvious first stop, and it does give you real information: sent and received bytes per process, updating live. Sort by "Sent Bytes" and the heavy uploader usually rises to the top.
Where it runs out is context. It shows a cumulative total since the process started, so a backup that finished an hour ago still looks enormous while contributing nothing right now. It also names processes, not apps - a helper called something like com.vendor.syncagent tells you little if you do not already recognise it. And it has no history, so if the upload stops while you are looking, the evidence disappears with it.
nettop in Terminal gives a live per-process view with actual throughput rather than totals, which is a genuine improvement. It is still a live view only, and it still speaks in process names and IP addresses.
Getting to a name and a number
What you actually want is the app, the destination, and how much has moved over a period you choose. That is what a per-app network monitor gives you. With App Firewall, the sequence is short:
- Open the live monitor and see which apps are opening connections right now.
- Switch to data usage for totals per app rather than a moment-in-time snapshot.
- Sort by data sent to bring the uploader to the top.
- Check the connection map if the destination looks wrong for that app.
- Pause or block it and watch whether your connection recovers.
The last step is the one that turns a guess into a confirmation. If throughput drops the moment you cut off a specific app, you have your answer. If it does not, you have eliminated a suspect, which is nearly as useful.
Pause or block?
This distinction matters more than people expect, and getting it wrong is how you end up with a backup that has not run since March.
Pause anything whose job you actually want done, just not now. Photo sync, cloud backup, and file sync all fall here. You want them running at full speed the moment you are back on a connection you are not paying for by the gigabyte. A permanent block on your backup tool is a data loss incident waiting for its moment.
Block things that had no business uploading in the first place. Analytics from an app you use offline, a helper left behind by software you removed, a vendor updater that checks in far more often than any release schedule justifies. These do not need to come back.
If you are unsure which category something is in, pause it and see what breaks over the next day. That is cheaper than reasoning about it.
Metered connections deserve a standing setup
If you are regularly on tethering, hotel Wi-Fi, or a satellite link, treat this as a configuration rather than a one-off investigation. Decide in advance which apps are allowed to use bandwidth when you are away from your usual network, and cut the rest off before they start rather than after you notice.
The apps worth pre-emptively pausing are the ones designed to saturate a connection: cloud backup, photo sync, and anything that downloads large updates automatically. None of them will suffer from a few days of waiting. Your allowance will.
When it is not an app at all
Occasionally the upload is not yours. A device on the same network doing its own backup, a roommate's console downloading a game, or a router with an unexpected guest will all produce the same felt symptom: everything is slow and nothing you own explains it.
The tell is that per-app data usage on your Mac stays flat while the connection is clearly loaded. At that point the investigation moves off your machine and onto the network - see which devices are connected and what they are doing, rather than continuing to search your own process list for a culprit that is not there.
The short version
Sustained background uploads are nearly always sync, backup, or a helper you forgot about. Find the app by sorting on data sent, confirm it by cutting it off and watching the connection recover, then pause the ones you still want and block the ones you never did. It is a ten-minute exercise that stops repeating itself.