How to Monitor Server Bandwidth Usage

What to measure: bits, bytes and direction

To monitor server bandwidth, read the interface counters with vnstat for history, iftop or nethogs for live traffic, and cPanel's Bandwidth page for per-domain totals. Set an alert at 80% of the plan cap. A spike is usually backups, a scraper, video or a compromised account, not normal growth.

Two numbers get mixed up. Bandwidth is capacity, measured in megabits per second. Usage is volume, measured in gigabytes per month. A 1 Gbps port can still burn through a monthly allowance in a day.

• Inbound and outbound are counted separately by the kernel. Most panels add them, so check which figure the cap uses.
• Live tools show a rate; they do not store history. History is what tells you whether this month is abnormal.
• Shared hosting caps monthly bytes. Some VPS and transit contracts bill the 95th percentile of a rate instead.

Read history with vnstat

vnstat keeps a small database of interface counters, so it answers "how much this month" without a graphing stack. It is not installed by default on most images.

1. Install it: sudo apt update && sudo apt install vnstat, then sudo systemctl enable --now vnstat.
2. Find the real interface name: ip -br a. Modern Ubuntu uses names like ens3 or enp1s0, not eth0.
3. Read the summary: vnstat -i ens3, then vnstat -i ens3 -d for days and -m for months.
4. Find the worst day: vnstat -i ens3 -t. That day usually explains the month.
5. Watch a live rate from the same database: vnstat -i ens3 --live.

You know it is recording when the rx and tx totals move after an hour of traffic. If they stay at zero, the interface name is wrong or the service is not running; check systemctl status vnstat.

Watch live traffic with iftop and nethogs

iftop shows which host pairs are moving data; nethogs shows which process is doing it. Run both for a minute during a spike and you usually have the answer.

1. Install both: sudo apt install iftop nethogs.
2. Start iftop on the right interface: sudo iftop -i ens3 -nNP. The flags keep addresses numeric and show ports.
3. Press t for running totals, s or d to sort by source or destination, and q to quit.
4. Run sudo nethogs ens3 in a second shell to see the process behind the traffic, such as a backup agent or php-fpm.

iftop reports rates, not monthly totals, so do not use it to decide how close you are to a cap. Use it to identify the top talker, then confirm the volume in vnstat or cPanel.

Check cPanel Bandwidth per domain

On a cPanel account, open Metrics, then Bandwidth, and pick the current month. The table lists each domain and the HTTP, mail and FTP bytes it used, which is the number a shared plan's allowance is measured against.

• cPanel recalculates bandwidth once a day, so today's row can lag by several hours.
• The per-domain rows add up to the account total. A single addon domain can be the whole spike.
• Bandwidth is not disk usage. A full disk is a separate page, and the fix is different.
• If the page is empty for a new account, wait for the next daily run before assuming zero traffic.

Write the month-to-date figure down before you change anything. That baseline is how you prove the fix worked at the end of the month.

Set an alert before the cap

An alert at 80% leaves room to act. On shared hosting, enable the bandwidth notification in cPanel's Contact Information so the account email gets the warning. On a VPS, a cron check against the kernel counters is enough.

1. Get the cap from the plan page or invoice, and set the threshold at 80% of it in gigabytes.
2. Add a cron entry that reads the counters and mails you once the threshold is crossed: */10 * * * * rx=$(cat /sys/class/net/ens3/statistics/rx_bytes); tx=$(cat /sys/class/net/ens3/statistics/tx_bytes); gb=$(( (rx+tx)/1073741824 )); [ "$gb" -gt 800 ] && echo "ens3 at ${gb} GB" | mail -s "bandwidth alert" you@example.com
3. Test it once by lowering the number to 0, confirming the mail arrives, then putting the real threshold back.
4. Remember the kernel counters reset on reboot. vnstat stays the source of truth for the month.

For a stricter alert, run the same check hourly and compare the delta to the same hour last week. A jump of more than 50% is worth a look even below the threshold.

What a spike usually means

A spike has a shape, and the shape names the cause. Match the pattern before you open a ticket or buy a bigger plan.

A number alone cannot tell you whether to optimise or upgrade. The per-domain and per-process view turns the spike into a name, and a name has a fix.

Cut usage before you buy more bandwidth

Most spikes are cheaper to remove than to host. Work down this list before you change plan, because extra allowance hides the same fault at a higher price.

• Enable page caching and compression. On LiteSpeed, the LSCache plugin removes most repeat PHP work and the bytes that come with it.
• Recompress large images to WebP and serve the right size. A 2 MB hero image on every page is bandwidth you chose to send.
• Move video and large downloads to object storage or a CDN, so the web server stops carrying them.
• Block hotlinking in .htaccess, and rate-limit login and API endpoints that bots hammer.
• Upgrade only when the traffic is clean and still near the cap. A VPS or cloud plan is quoted by email before payment when that day comes.

For the definitions behind these numbers, the bandwidth explainer covers the difference between capacity and volume. If the disk is filling at the same time, start with freeing disk space on Linux, because a full disk stops logs and can hide the traffic cause.