How to Check Bandwidth Usage When the Graph Looks Fine

Updated: November 2026

To check bandwidth usage on one Windows PC, open Settings > Network & Internet > Advanced network settings > Data usage for per-app totals, or run resmon and open the Network tab for live per-process traffic. To find which device on a network is using the bandwidth, open the per-client traffic report on your router or firewall if it has one, or turn on flow export (NetFlow or IPFIX) and read it in a collector. A speed test measures how fast the connection is and shows nothing about which device used 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. Check for both before you buy software.
• Per interface. SNMP interface counters give totals only, never who used them.
• The number can be wrong. Bits against bytes is an 8x error, and a five-minute average can hide 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."

What Bandwidth Means in Networking

Bandwidth is the maximum rate a link can carry data, measured in bits per second: a 500 Mbps line can move at most 500 megabits every second. Throughput is what flows in practice, and it never exceeds the bandwidth. Usage is the total transferred over time, counted in bytes. A complaint about "bandwidth" can be about either of the other two.

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. Treat it as recent history for one machine, and take billing figures from the ISP or the gateway.

Task Manager's App history tab is a second place to look. It shows network use per app, and on Windows 11 it includes desktop programs as well as Microsoft Store apps, unless a setting in Task Manager has narrowed it to Store apps. Settings > Data usage stays the quicker list for ranking what used the most data.

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

code
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.

Leo Notenboom of Ask Leo! walks through Resource Monitor's Network tab, including sorting processes by bytes sent and received and reading the remote addresses each one talks to.

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

The top answer in the r/HomeNetworking thread above says it first: your gear may not be able to do this. "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."

The person asking wanted a cheap way to see it on the router and modem they had bought on Reddit recommendations. Another commenter answered "They are all going to be different," and noted that their own Asus router shows total and per-client bandwidth on a performance tab, so the router's admin pages are the first place to look. On a Spiceworks thread with the same question, the person asking set out a clear requirement: catch devices by MAC address rather than IP, because IPs change, then attribute how much data to which device and ideally which application.

Where per-client usage lives on common gateways:

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 show the rate at that moment, with no running total, so 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 nothing on the network 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 suit an afternoon of diagnosis.

Why Interface Counters Cannot Tell You Who

This is the structural fact behind the wasted afternoons on this problem.

The IF-MIB, the interface table that SNMP bandwidth monitoring reads, 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. Our guide to SNMP OIDs shows how to find those counters on a device.

Flow export is the answer, and the three formats differ:

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 gap is normal and needs no fix. Our explainer on what NetFlow is covers the record format and how collectors report it.

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

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. SNMPv1 cannot carry 64-bit counters at all, and a v1 walk skips those objects without an error, so a poller left on v1 keeps reading the 32-bit counters without any warning.

Measuring on the wrong side. NAT replaces the internal address with the public one on every packet it translates. 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 is the only option 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 question widens to which site is busy, and whether this month looks like last month.

Spot checks do not answer that. Broadband data firm OpenVault, which measures usage across the operator networks it monitors, found in its 1Q25 report that 23.4 percent of subscribers changed usage tiers between February and March 2025. Across the 24 months to March 2025, only 61 percent of its heaviest users, on 5 TB or more a month, stayed in that tier the next month, and business subscribers' peak-day upstream usage has risen 102.6 percent since the end of 2021. A quarterly sample misses that movement.

Total consumption keeps climbing too. OpenVault's 2Q25 report puts average household consumption at 664.2 GB a month, up 13.4 percent year over year.

The operational problem is different too. A sysadmin on r/sysadmin 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 one reason flow export gets refused: older gear near end of life that nobody wants to add overhead to.

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 our open, AI-native infrastructure for IT and security. It puts monitoring, remote access, patching, help desk tickets and logs in one console, at $1 per device a month, or $0.80 billed annually with 25 million AI tokens, and its AI agents, Fae and Mingo, work the resulting tickets in that same console. There is a 14-day trial.

Where to Go Next

Decide which question you have before you pick a tool. A speed test proves the pipe. Per-device measurement inside the NAT boundary proves who filled it.

Two things worth doing this week. Check whether your monitoring is polling 64-bit interface counters, because on the 32-bit path a busy gigabit link wraps between polls and nothing flags the bad readings. 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.