How to See Real-Time Network Usage on macOS

"Real-time" is one of those words that means different things to different tools. A trading app means microseconds. A weather app means "in the last five minutes." When you want to see real-time network usage on macOS — to debug a stuck upload, to confirm a setting change took effect, to find which tab is hammering your bandwidth — you need updates fast enough to track human-scale events. About once a second is the sweet spot. Faster gets noisy; slower misses spikes.

This is a tour of how to get there with the tools macOS ships, what each one actually shows you, and where the term "real-time" hides important tradeoffs.

What "real-time" actually requires

A network monitor that feels real-time has to do three things:

1. Sample the kernel often enough. macOS exposes per-process byte counters through the same mechanism nettop uses (PF_SYSTEM/PF_SYSTEM_NDR sockets, route info, and process accounting). Sampling at 0.1 Hz feels laggy. Sampling at 10 Hz spikes CPU. Around 1 Hz is the standard.
2. Compute deltas. The raw counters are cumulative bytes since process start. To get a rate, you subtract the previous sample from the current one and divide by elapsed time.
3. Smooth the result. Network traffic is bursty at sub-second timescales. A 1-second window already smooths most of that, but UIs typically apply an additional moving average so the displayed number doesn't jump from 0 to 50 MB/s and back to 0 every tick.

A tool that doesn't smooth feels twitchy. A tool that smooths too aggressively feels delayed. The sweet spot is a 1-second sample with a 2–3 sample exponential average.

Tool 1: Activity Monitor

Activity Monitor's Network tab updates every couple of seconds. The key columns:

• Sent Bytes / Rcvd Bytes — cumulative since the process started.
• Sent Packets / Rcvd Packets — same, in packets.
• Bytes Read/Sec — per-second rate (you may need to enable this column via View → Columns).

The bottom panel shows a system-wide rate graph. You can switch the graph between Packets and Data.

What Activity Monitor is good at:

• Quick visual sort by who's used the most cumulative data since launch.
• A reasonable system-wide rate graph.

What it's not great at:

• Update rate. The default refresh is 5 seconds (configurable via View → Update Frequency). At 5 seconds, you miss short spikes entirely.
• Helper folding. Chrome shows up as 7+ separate processes. You have to add them mentally.
• History. Close it and the rate data is gone.

Tool 2: nettop

nettop is the closest thing macOS ships to a real-time per-process network monitor. The most useful invocation:

nettop -P -t wifi -d

• -P shows process name per row (otherwise grouped by PID, which is unreadable).
• -t wifi filters to the Wi-Fi interface; use -t wired for ethernet.
• -d shows per-second deltas. Without this flag you see cumulative totals and have to do the subtraction in your head.

You can also pass -l 1 to print a single sample and exit, which is useful for scripting.

The columns that matter:

• bytes_in / bytes_out — bytes received and sent in the last sample window.
• interface — which NIC is carrying the traffic.
• state — the TCP state (Established, TimeWait, Listen, etc.).

nettop is faster, more granular, and more honest about what's happening than Activity Monitor. Its downsides:

• Terminal UI. You can't keep it visible while doing other work without dedicating a window to it.
• No history. Quit nettop, lose the last 30 seconds.
• No helper folding. Chrome's helpers appear as separate rows.
• Update rate defaults to 1 second; faster means more terminal flicker.

Tool 3: A menu bar monitor

The reason menu bar bandwidth monitors exist is that "real-time" is most useful when it's ambient. You want to see the rate without thinking about it — without opening an app, switching tabs, or running a command. The menu bar is the only UI surface on macOS that meets this criterion: always visible, almost no screen cost, single-click to expand.

ova is built around this. It samples at about 1 Hz, displays the current up/down rate in the menu bar, and on click expands to a per-app list sorted by current bandwidth. Helper processes (Slack Helper, Google Chrome Helper, Discord Helper, etc.) are folded back under their parent app so you don't have to mentally sum across rows.

The other thing a menu bar monitor gives you that nothing else does: history. Real-time is half the picture. The other half is "what was the rate at 2:47 PM yesterday when my laptop got hot?" A monitor that keeps a local time series can answer that. nettop can't.

Real-time, in the menu bar

Per-app bandwidth monitor that samples at 1 Hz and stores history locally. ~3 MB, signed, no account.

Download for macOS

What about latency, not bandwidth?

A common confusion: "real-time network usage" sometimes means bytes per second and sometimes means packet round-trip latency. They're different problems and different tools.

• Bandwidth (bytes/sec): Activity Monitor, nettop, ova.
• Latency (ms round-trip): ping, mtr, iputils, network utility tools that show jitter and packet loss.

If your video call is choppy, bandwidth might not be the issue — latency or packet loss is. Bandwidth tools won't tell you that.

For a quick latency check:

ping -c 30 1.1.1.1

This sends 30 ICMP echoes. The output shows min/avg/max round-trip and packet loss. Anything under 30 ms with 0% loss is healthy for typical home use.

Tradeoffs in real-time monitoring

A few things to know if you care about precision:

Sampling vs counting

nettop and most menu bar tools sample. That means a TCP connection that opens, transfers 100 KB, and closes inside a 200 ms window between samples might not show up in your monitor — it'll be folded into the next sample as part of the running total. For most "find the heavy app" use cases, this is fine. For traffic forensics, use a packet capture tool like tcpdump or Wireshark.

Per-process vs per-interface

Per-process counters are aggregated by macOS's process accounting layer. They're accurate for established TCP/UDP flows but miss some kernel-level traffic (KEXT-driven VPN tunnels, certain network extensions). The interface-level counters from netstat -ib will always be higher than the sum of per-process counters because of this overhead.

Wi-Fi vs ethernet

If you have both Wi-Fi and ethernet attached, every monitor needs to know which to report. Activity Monitor sums them by default. nettop has the -t flag. ova shows them separately so you can tell whether traffic is going over the wire or over the air.

When "real-time" is overkill, and when it's not

Real-time monitoring is the right tool when:

• You're debugging a stuck transfer.
• You're verifying a setting change worked.
• You're trying to find a runaway process.
• You're tethered and need to know what's eating your data.

It's the wrong tool when:

• You want to know your monthly data total — use a per-day or per-week aggregate instead.
• You want to alert on threshold breaches — set up a per-day cap, not a per-second one.
• You're investigating something that happened yesterday — use historical view, not live.

A good monitor offers both modes. ova does — live menu bar plus a scrubable timeline of past traffic. The two views answer different questions, and you'll find yourself bouncing between them. The live view tells you what's happening now; the historical view tells you what was happening when something interesting started. Neither view alone is enough for the full set of bandwidth questions a normal week throws at a Mac user.

A pattern that comes up often: you notice a spike in the live view, but by the time you click in to investigate, the spike is gone. The historical view rescues you. Look at the last 60 seconds, find the per-app row that just lit up, and you have your answer even though the live picture is back to baseline.

Wrapping up

To see real-time network usage on macOS:

1. Quick spot check: nettop -P -d in a terminal. Built in, no install.
2. System view: Activity Monitor → Network tab. Cumulative-only, refresh limited.
3. Always-visible per-app rate: a menu bar monitor like ova. One-second sampling, helper folding, local history.

Real-time is most useful when it's ambient. The cost of "always on" should be near zero — under a percent of CPU, no telemetry, no cloud round-trips. ova is about 3 MB, runs on macOS 14 and up, supports Apple Silicon and Intel, samples at 1 Hz, and keeps every byte of data on your Mac. One-time payment, lifetime updates, 14-day refund.