nload: Watch Live Network Bandwidth in the Terminal

nload draws a live, scrolling graph of incoming and outgoing bandwidth on a network interface, right in your terminal. Run nload with no arguments and it picks the first non-loopback interface, shows two graphs (In and Out), and updates a few times a second with the current rate plus the average, min, max, and total transferred. It is the fastest way to answer "is this box actually saturating its link right now" without leaving the shell.

The thing to know up front: nload is a traffic-rate monitor, not a per-connection or per-process one. It tells you the interface is moving 400 Mbit/s; it does not tell you which host or which process is responsible. For that you reach for iftop (per-connection) or tools like nethogs (per-process). nload is the glance-at-the-pipe tool, and that narrow job is exactly why it is so quick to read.

Install nload

It is not in the base install on most distros, so grab it from the package manager first.

# Debian / Ubuntu
sudo apt install nload

# Fedora / RHEL / Rocky (EPEL on RHEL family)
sudo dnf install nload

# Arch
sudo pacman -S nload

# macOS (Homebrew)
brew install nload

The package is the same upstream project everywhere: Roland Riegel's nload. There is no daemon and nothing to configure; it reads counters straight out of /proc/net/dev on Linux, so it works the moment it is installed.

Run it

nload

That opens the full-screen display on the first real interface it finds. The top half is incoming traffic, the bottom half outgoing, each with a scrolling bar graph and a stats block to the right:

Device eth0 [192.0.2.10] (1/2):
======================================
Incoming:
                                         Curr: 412.18 MBit/s
   .|||                                  Avg: 388.04 MBit/s
  .||||.   .|                            Min: 0.00 Bit/s
.|||||||| .|||.                          Max: 451.77 MBit/s
||||||||||||||||                         Ttl: 18.42 GByte
--------------------------------------
Outgoing:
                                         Curr: 6.91 MBit/s
                                         Avg: 5.88 MBit/s
   .|                                    Min: 0.00 Bit/s
.|.||.  .|                               Max: 12.04 MBit/s
||||||||||||                             Ttl: 1.07 GByte

Curr is the rate right now, Avg is the running average over the averaging window, Min and Max are the lowest and highest rates seen, and Ttl is the cumulative bytes transferred while nload has been running. The (1/2) in the header means interface 1 of 2; the left and right arrow keys cycle between them.

Press q or Ctrl+C to quit. F2 opens the options screen; F5 saves the current settings; F6 reloads them.

Switch interfaces

Two ways. Cycle live with the arrow keys, or name the interface on the command line so nload starts on it directly:

nload eth0

You can pass several and nload will let you page through just those with the arrows:

nload eth0 wg0 docker0

To see them all at once instead of one per screen, use the multiple-devices view.

Show every interface at once with -m

nload -m

-m switches to multiple-device mode: each interface gets a compact two-line In/Out summary stacked on one screen, no scrolling graph. This is the view I actually use on a busy host, because the question is usually "which interface is hot", and a wall of small In/Out readouts answers that faster than paging through full graphs one at a time.

Fix the scale and the units

The graph's 100% mark defaults to a fixed 10240 kBit/s (10 Mbit/s), so on a gigabit link the bars peg to the top constantly and tell you nothing. Set the mark to your link's real rate so the height means something:

nload -i 102400 -o 102400 eth0

-i sets the top of the incoming graph and -o the outgoing, both in kBit/s. 102400 kBit/s is 100 Mbit/s, so a full-height bar now means a saturated 100 Mbit link. Passing -i 0 switches that graph to auto-scaling instead, where the bars always fill the height and the y-axis label tracks traffic up and down: handy on a link whose ceiling you do not know, distracting on one you do.

The display units are controlled separately:

nload -u M -U G eth0

-u sets the unit for the traffic rates (the Curr/Avg/Max lines) and -U the unit for the totals (Ttl). The letters are: b k m g for bits (Bit/s, kBit/s, ...) and B K M G for bytes, plus h (or H) for human-readable auto-scaling. The defaults are -u k (rates in kBit/s) and -U M (totals in MByte), so -u M forces rates into MBit/s and -U G forces totals into GByte, which keeps the numbers steady instead of flipping units as traffic changes.

Change the refresh interval

nload -t 200 eth0

-t is the refresh interval in milliseconds (default 500). Lower it to 200 for a twitchier graph that reacts faster to bursts; raise it to 2000 for a calmer, more averaged readout on a noisy link. It only affects the display refresh, not how often the kernel counters update.

Flag reference

-a is the one people miss: it sets how many seconds of history the Avg line covers. The default is 300, so Avg is a five-minute mean. Shorten it if a long average is hiding short spikes you care about.

A worked example: confirm a transfer is saturating the link

Say a backup over the network feels slow and I want to know whether the link is the bottleneck or something upstream is throttling. I pin the scale to the link's rated speed and force MBit/s so the reading does not jump around:

nload -u M -i 1024000 -o 1024000 eth0

1024000 kBit/s is roughly 1 Gbit/s, so the incoming graph now fills the height only when the link is genuinely maxed. If Curr parks at ~940 MBit/s and the bar is pinned to the top, the wire is the limit and there is nothing to tune on this box. If it sits at 300 MBit/s with the bar a third of the way up while the transfer crawls, the bottleneck is elsewhere (disk, the sender, a shaper in the path), and nload has just saved me from chasing the wrong thing.

When NOT to use nload

nload is great at one question and silent on the rest. Reach for something else when:

• You need per-connection detail. "The interface is busy" is not "host X is hammering port 443". iftop breaks the same traffic down by connection with source, destination, and per-flow rates. See iftop: per-connection bandwidth in the terminal.
• You need per-process attribution. When you want to know which program is using the bandwidth, nethogs groups traffic by PID. nload has no concept of processes.
• You are auditing what is listening, not what is flowing. Open ports and reachable services are a scanning job, not a rate-monitoring one. nmap (and ss -tlnp locally) answer that. See nmap command examples.
• You want history and alerting. nload only shows the live window; it stores nothing. For graphs over days and threshold alerts you want a real collector (Prometheus + node_exporter, vnstat for long-term totals, or your monitoring stack).
• The bottleneck is the disk, not the wire. A slow transfer with the link nowhere near saturated usually means I/O is the limit. iotop tells you which process is hammering the disk, which is the natural next check after nload rules out the network.

For a quick "is the pipe full right now" check on any box you can SSH into, nload is exactly the right amount of tool.

See also

• iftop on the command line: the per-connection counterpart, breaking interface traffic down by host and flow when nload's aggregate number is not enough
• iotop: find the process hammering your disk: the same live-monitor idea for disk I/O, the check to run when a transfer is slow but the link is not saturated
• nmap command examples: when the question is which ports and services are reachable rather than how much traffic is moving
• External: nload source on GitHub, Debian nload(1) man page.

FAQ