How to Check Bandwidth Usage When the Graph Looks Fine

Three different questions arrive at this page, and only one of them is about bandwidth usage. Some people want to know how fast the connection is, which is a speed test. Some want to know how much data their hosting account transferred, which lives in cPanel under Bandwidth. And some want to know which device on the network ate 400 GB last month, which is the hard one and the one this covers. The difference matters because the tools do not overlap: a speed test measures the pipe, and it tells you nothing about what is flowing through it.

TL;DR

• Per machine. Windows Settings has per-app data usage, and Resource Monitor shows live per-process traffic.
• Per device. Your gateway needs flow export or per-client stats. Most consumer gear has neither.
• Per interface. SNMP interface counters give totals only, never who used them.
• The number is often wrong. Bits against bytes is an 8x error, and a five-minute average hides a fully saturated link.
• Measure inside the NAT boundary. Upstream of translation, the internal address is gone for good.

Three Questions Hide Behind One Search

Sort out which one you have before you open anything, because the wrong instrument gives a confident answer to a question you did not ask.

A speed test also consumes the thing you are measuring. Run the arithmetic: rate times duration divided by eight. A fifteen-second download phase on a gigabit link moves roughly 1.9 GB, and both phases together about 3.8 GB. On a capped circuit or a cellular failover, repeated testing becomes one of the largest consumers in the log. A commenter in the r/HomeNetworking thread that ranks for this search put it more plainly: "Ironic that speed tests that run use most of my bandwidth."

Check One Windows Machine

Start here when a single user reports the problem, because it takes a minute and rules out the obvious.

Settings > Network & Internet > Advanced network settings > Data usage gives you per-application totals ranked by consumption. This is the view that catches a sync client re-uploading a library or a backup agent that never finished. Microsoft does not document how far back the window reaches, so treat it as recent history rather than a billing record.

Task Manager's App history tab looks like the same thing and is not. It covers Store and UWP applications. Traditional Win32 and MSI-installed software, which is most of what a business machine runs, never appears there by design. The "show history for all processes" toggle does not change that. Reach for Settings > Data usage instead, and use App history only to confirm a Store app.

For live traffic rather than history, Resource Monitor is the one worth knowing:

resmon

Its Network tab lists every process with current send and receive rates, the remote address each is talking to, and the port. Leave it running on a second monitor while the user reproduces the problem. That combination, a live per-process rate next to a live complaint, is what turns "the internet is slow" into a named executable.

From PowerShell, two commands give you interface totals:

powershell
Get-NetAdapterStatistics | Select-Object Name, ReceivedBytes, SentBytes
netstat -e

Get-NetAdapterStatistics runs natively on both Windows PowerShell 5.1 and PowerShell 7, no compatibility shim involved, and it is Windows-only. Both return counters since the adapter last reset, so a reboot zeroes them. Neither attributes a single byte to a process.

Find the Device Eating the Link

Here is the part no ranking article says out loud, and the top-voted answer on the highest-traffic thread for this search says it first: your gear probably cannot do this. The reply, at 12 points: "You need network gear that supports instrumentation, data collection and/or scripting. Most home network appliances/gear is designed for simplicity and doesn't provide such features."

That thread never resolves. The person asking had bought a well-reviewed consumer router and wanted to know where the per-device numbers lived. A network admin answered "They are all going to be different," and the conversation stopped there. On a Spiceworks thread with the same question, the person asking had already tried four products and written the clearest requirement anywhere in this topic: catch devices by MAC address rather than IP, because IPs change, then attribute how much data to which device and ideally which application.

What reports per-client usage without a package bolted on:

OPNsense is the outlier worth knowing about: its Insight analyzer is built into the interface, so per-IP totals need nothing installed. Its retention is published, which is rare enough to be useful: thirty-second averages for the last two hours, five-minute for eight hours, hourly for a week, then daily for a month and a year. pfSense reaches the same destination through a package, and its own documentation is direct about the split, offering built-in graphs for per-interface usage and pointing you at a package when you need it by client IP.

Two cautions on that table. pfSense's Traffic Graph host table and MikroTik's Torch both look like usage meters and are not: they show instantaneous rate, and the documentation for the first describes it as momentary glimpses rather than averaged data. Short connections may never appear at all. And on MikroTik, the /ip accounting feature that older guides still recommend was removed in RouterOS v7.

When there is genuinely nothing on the network that can report, the old diagnostic still works. Put a hub inline temporarily and capture from a machine plugged into it, or mirror the router's switch port if the switch supports it. Both are for an afternoon of diagnosis, not a permanent arrangement.

Why Interface Counters Cannot Tell You Who

This is the structural fact that explains most wasted effort on this problem.

The IF-MIB, which is what almost everything means when it says SNMP monitoring, stores an interface index and a byte total. There is no source address, destination, port, protocol or application anywhere in its schema. You can prove that port 3 moved 40 GB. You cannot get one step closer to who moved it, no matter which poller you point at it.

Flow export is the answer, and the three options are not equivalent:

IPFIX is the only one of the three that is an actual IETF standard, RFC 7011, STD 77. NetFlow v9 is an Informational Cisco memo, RFC 3954, which says of itself that it is not a candidate for any level of Internet Standard. sFlow is packet-sampled by design, so its byte totals are extrapolated estimates rather than counted bytes, and its periodic counter samples are the same per-interface totals SNMP already gave you.

A flow record carries the five-tuple plus byte and packet counts, which is exactly the attribution the interface counter lacks. One detail saves a wasted hour later: flow records count Layer 3 bytes while ifInOctets counts Layer 2 including framing. The two will not match for the same traffic, and flow reads lower. That is expected, not a fault to chase.

Support is uneven in ways worth checking before promising a client anything. MikroTik does NetFlow v5, v9 and IPFIX but no sFlow. OPNsense exports v5 and v9 with no IPFIX. pfSense Plus added native export at Firewall > Packet Flow Data, and that feature is absent from pfSense CE, which needs the softflowd package instead. Meraki MX does NetFlow v9 only.

The Traps That Make the Number Wrong

Four ways to measure carefully and still get a wrong answer.

Bits against bytes. Windows performance counters, Get-NetAdapterStatistics, netstat -e, SNMP octet counters and flow records all report bytes. OPNsense reports bits. ifSpeed is bits per second. Mix a byte counter into a utilization calculation against a bit-per-second link speed and you are out by a factor of eight, which is the difference between reporting twelve percent utilization and reporting a saturated link.

The averaging interval. A five-minute poll divides bytes moved by elapsed time, and everything inside that window collapses into one number. On a 100 Mbps link:

A VoIP call breaks up during a thirty-second saturation event and the graph shows a calm ten percent line. Meraki documents the same effect in its own words, noting that bursts of traffic at high speed appear lower when surrounded by low utilization. It gets worse as data ages, because RRD-based tools consolidate old samples into averages of averages and the peaks are gone permanently.

Counter wrap. A 32-bit SNMP counter holds about 4.29 billion bytes. RFC 2863 states the consequences directly: a saturated 10 Mbps link wraps it in just over 57 minutes, 100 Mbps in 5.7 minutes, and 1 Gbps in 34 seconds. At gigabit with a standard five-minute poll that is roughly nine wraps between readings, and a wrap is indistinguishable from a small delta, so the poller reports a plausible low number and nothing flags it. The fix is the 64-bit counters in ifXTable, ifHCInOctets and ifHCOutOctets, polled over SNMPv2c or v3. The reason estates sit on the broken path for years is that an SNMPv1 query for those objects does not error, it silently returns nothing.

Measuring on the wrong side. NAT does not aggregate the internal address, it removes it. Anything counting upstream of translation, including the ISP portal and WAN-side counters, sees only post-translation packets, and no downstream analysis recovers the original source. Measure at or inside the NAT boundary: the firewall's LAN interface, a collector on the LAN segment, or flow export from the NAT device itself, which is the only box that sees both sides at once. Under carrier-grade NAT the site's own WAN address is shared and translated again, so LAN-side measurement stops being the better option and becomes the only one you control.

One more that catches people with a gateway-based tool: traffic switched within a VLAN never reaches the gateway, so it is invisible. Meraki states it plainly, that hardware-switched traffic inside the same VLAN gives the MX nothing to report on. A backup job between two servers on the same segment can saturate a switch while every gateway graph stays flat.

Checking Bandwidth Across Client Sites

Everything above assumes one network. Across twenty of them the problem changes shape, because the question stops being which device and becomes which site, and whether this month looks like last month.

Spot checks do not answer that. Broadband data firm OpenVault, measuring its operator install base, found that between February and March 2025 nearly a quarter of subscribers moved into a different usage tier, and among power users on a terabyte or more, 39 percent did. Consumption is not a stable number you can sample once a quarter. The same data puts average household consumption at 664.2 GB a month in the second quarter of 2025, up 13.4 percent year over year, and business subscribers have seen peak-day upstream more than double since the end of 2021.

The operational problem is different too. A sysadmin on r/sysadmin last October described chasing a saturated gigabit link across three dozen access switches by opening the monitoring tool and clicking through 48 interfaces per switch. That is the failure mode: the data exists, and finding it costs an afternoon. The same thread named the reason flow export often gets refused, which is that older gear is near end of life and nobody wants to add overhead to it.

There is a sequence worth keeping. Establish what normal looks like per site before an incident, so a graph has something to be compared against. Measure inside the NAT boundary so per-device attribution survives. Turn on flow export where the hardware supports it and fall back to 64-bit interface counters where it does not. And treat a threshold alert as the thing that wakes someone up, with the dashboards for everything else.

That is where a console stops being the right tool and platform work starts. Collecting per-site network data, keeping the history, and alerting on a threshold across every client at once is what monitoring inside an RMM is for. OpenFrame is ours, and the thing worth knowing is the shape of it: open source at $1 per device per month, with RMM, patching, remote access, documentation and SIEM in one place instead of four contracts. The agents in it, Fae and Mingo, work the resulting tickets inline rather than handing a technician another dashboard to read.

Where to Go Next

Decide which question you have before you pick a tool, because that single choice explains most of the wasted effort on this problem. A speed test proves the pipe. Per-device measurement inside the NAT boundary proves who filled it. They are different instruments and they are not substitutes.

Two things worth doing this week. Check whether your monitoring is polling 64-bit interface counters, because if it is on the 32-bit path at gigabit, every reading it has ever taken is wrong and nothing told you. And capture a normal week per client site now, while nothing is broken, so the next saturated link has a baseline to be measured against.

For where the tooling side of this goes, our comparison of network management software picks up where the command line stops.