If your VPS plan comes with a monthly bandwidth allowance, you've probably had that moment: an invoice email mentions an overage charge, or your provider throttles the connection, and you have no idea which day — or which process — burned through the quota. vnstat fixes that blind spot. It's a tiny, low-overhead daemon that quietly logs your network interface's traffic in the background, so when something spikes, you can actually go back and see when it happened instead of guessing.
Symptom
A few ways this usually shows up:
- Your hosting dashboard shows bandwidth usage climbing fast, but you don't know if it's real traffic, a bot, or a misconfigured backup job.
- You got a "nearing your bandwidth limit" warning mid-month with no obvious cause.
- Outbound traffic looks abnormally high and you suspect the server is relaying spam, running a compromised script, or serving as an open proxy.
- You want historical data — daily/monthly totals — and
toporhtoponly shows you what's happening right now.
Cause
Most VPS images don't ship with any persistent network accounting by default. Tools like iftop or nload show live throughput, which is useful for "what's happening right now" but useless once the terminal closes — nothing is saved. Without a logging tool running continuously, by the time you notice a bandwidth problem, the traffic that caused it is long gone from memory. vnstat solves this by reading interface byte counters at regular intervals and storing the deltas in a small database, so you get real day-by-day and month-by-month history.
Fix
1. Install vnstat
On AlmaLinux/Rocky/CentOS-based VPS:
sudo dnf install epel-release -y
sudo dnf install vnstat -yOn Ubuntu/Debian:
sudo apt update
sudo apt install vnstat -y2. Start and enable the service
sudo systemctl enable --now vnstat
sudo systemctl status vnstatIt should show active (running). If it doesn't start, check journalctl -u vnstat -n 50 — the most common cause is the interface name in its config not matching your actual NIC.
3. Confirm it's watching the right interface
Find your primary interface name first:
ip -brief link showYou'll typically see something like eth0, ens3, or enp1s0. Then check what vnstat is tracking:
vnstat --iflistIf your interface isn't being monitored, add it manually:
sudo vnstat -u -i ens3On newer versions vnstat auto-detects interfaces, but on minimal cloud images it sometimes misses interfaces that appear after boot (common with some KVM/Xen setups) — running the command above forces it to pick it up.
4. Let it collect data
This is the part people skip and then get annoyed about: vnstat needs time to build a baseline. Give it a few hours minimum, ideally a full day, before trusting the numbers. In the meantime you can still check live throughput:
vnstat -l -i ens3This live mode is handy for confirming which interface has real traffic before you wait around for historical data.
5. Read the reports
Once it's been running a while:
# Summary across all tracked periods
vnstat
# Daily breakdown
vnstat -d
# Monthly totals — this is the one that matters for overage billing
vnstat -m
# Hourly breakdown for today (great for finding *when* a spike happened)
vnstat -hThe monthly view is what you want to compare against your hosting plan's bandwidth cap. If one day's total looks way out of line with the rest, cross-reference it with vnstat -h for that date to narrow down the hour, then check your web server or mail logs for that window.
6. Narrow down the culprit process (optional but useful)
vnstat tells you the interface totals, not which process is responsible. If you need to catch a live spike in the act, pair it with:
sudo apt install nethogs -y # or dnf install nethogs
sudo nethogs ens3nethogs shows per-process bandwidth in real time, so if a spike is happening right now you can see exactly which PID is responsible — often a runaway backup script, a compromised cron job, or a misbehaving plugin making outbound requests.
7. Get a JSON export for scripting or alerting
If you want to pipe usage data into a monitoring dashboard or a simple alert script:
vnstat --json mYou can cron a small script that checks the current month's total against your plan's cap and emails you (or hits a webhook) once you cross, say, 80% usage — well before the provider's own overage notice lands.
Prevention
| Practice | Why it helps |
|---|---|
| Install vnstat on every new VPS during initial setup | You get historical data from day one instead of only after a problem appears |
| Set a cron job to email monthly totals | Catches slow, gradual increases before they become an overage |
| Watch for outbound spikes specifically | Unusually high outbound traffic (vs inbound) is a common sign of compromise — spam relaying, DDoS participation, or data exfiltration |
| Rate-limit or block scrapers/bots | Aggressive crawlers can quietly eat a large share of monthly bandwidth on content-heavy sites |
| Review backup job schedules | Large offsite backup transfers during business hours can look like a traffic spike if you're not expecting them |
vnstat by itself won't stop an overage — it just makes sure you're never blindsided by one. Once you can see daily and hourly trends, spotting the difference between "normal Tuesday traffic" and "something is wrong" becomes a five-second glance instead of a guessing game.
Frequently Asked Questions
Does vnstat measure bandwidth the same way my hosting provider bills it?
Usually close, but not guaranteed to be identical. vnstat counts raw bytes in and out on the interface you point it at. Some providers only bill outbound traffic, some bill combined in+out, and some exclude traffic to/from their own network. Treat vnstat as an early-warning tool and cross-check the first month against your provider's dashboard to confirm the numbers line up.
Will vnstat slow down my server?
No. It reads kernel interface counters at short intervals — there's no packet inspection or deep traffic analysis involved, so the CPU and memory footprint is negligible even on a small VPS.
I ran vnstat -m and it shows almost no data even though the service has been running for days. What's wrong?
This almost always means vnstat is watching the wrong interface, or a second interface (like a private/internal NIC) is the one actually carrying traffic. Run vnstat --iflist and ip -brief link show side by side and make sure the interface names match, then re-add the correct one with vnstat -u -i <interface>.
Can I monitor bandwidth on multiple interfaces at once?
Yes. vnstat tracks each interface separately once added — just run the per-interface commands with -i <name> for each one, or run plain vnstat with no flags to see a summary across all tracked interfaces.
What's the difference between vnstat and Netdata for this?
Netdata is a full real-time monitoring dashboard covering CPU, memory, disk, and network with live graphs, but by default it doesn't retain long-term historical totals in the same lightweight way. vnstat is purpose-built for exactly one job — logging network traffic history — and does it with almost no resource overhead, which makes it a good lightweight complement even if you're already running something heavier like Netdata.
