How to Check Network Traffic and Bandwidth Usage in Your Office

When backups run or the office gets busy, shared files may become slow to open. A rise in network traffic is a clue, but it does not show the cause on its own.

Start with reports you are authorised to access. Record the time, traffic readings and how long staff take to finish the affected task. Compare a busy period with a similar period when the task works normally.

This guide explains how to check bandwidth usage on network links without changing their settings. Use the findings to improve network efficiency and decide what to investigate before buying more capacity.

Understand traffic, capacity, counters and rates

Network traffic is data sent and received across a device or link. Bandwidth describes its capacity, usually in bits per second. Throughput is the data rate measured under particular conditions. None of these figures alone shows how quickly a staff member finishes a task.

Check the units. One byte equals eight bits. A report in bytes cannot be compared directly with a link speed in megabits per second, or Mbps.

A cumulative counter records an increasing total since a starting point or reset. It does not show the current rate. To calculate an average from a byte counter:

1. Subtract the earlier reading from the later reading.
2. Multiply that byte difference by eight to convert it to bits.
3. Divide by the seconds between readings.

For a hypothetical example, a counter that rises by 1,000,000 bytes over 10 seconds gives 800,000 bits per second, or 0.8 Mbps. This is an average over that window, not a peak speed or a reading from your office.

If a counter falls, check for a reset or wrap rather than reporting negative usage. A wrap occurs when a counter reaches its limit and starts again. A short busy spell can also disappear inside a daily average.

Start with reports you are authorised to access

Ask your IT administrator or supplier for an existing report on the office connection. Confirm the link, upload and download directions, time window and units. Check whether the figures cover one interface, the whole internet connection or several links together.

Router, firewall and supplier reports can use different sampling windows or measurement points. Comparing them without checking the scope can make normal differences look like a fault.

For a device-level example, Windows has Get-NetAdapterStatistics. Microsoft documents the adapter statistics it reports, including traffic-related counts, discards and errors. Ask an authorised administrator to interpret the relevant adapter rather than assuming all adapters represent the same connection.

A laptop’s counters cannot show traffic across the whole office. They also do not identify every application delay. Start with approved reports and collect only the detail needed for the investigation.

Record an office baseline and sampling window

Record the office, connection and application affected. Describe the task in ordinary terms, such as opening an order, uploading a file or completing a call. Include the date, Singapore local time and whether the device uses Wi-Fi or a cable.

Choose a window covering the reported slowdown and a comparable period when work is normal. Keep upload and download figures separate. Mark each reading as a counter or a rate, and retain its units.

Record	Why it helps
Task, location and connection method	Identifies what is being compared
Start/end time and sampling interval	Matches traffic readings with the slowdown
Upload/download figures and units	Shows direction and avoids unit mistakes
Task completion, failures and disconnections	Records the effect on actual work
Gaps, resets or changed conditions	Shows the limits of the evidence

Do not add readings from both ends of the same link as separate demand; that can count the same traffic twice. Likewise, distinguish a connection-wide report from a device report before combining results.

If wider monitoring is proposed, ask what link it covers, how often it samples and what records you can export. Agree these needs before paying for a tool or service.

Compare traffic with delay, loss and task completion

Repeat the affected task under agreed conditions. Record completion time, failed attempts and disconnections. Compare those results with relevant network readings from the same period.

Latency measures network delay. Packet loss concerns packets that do not arrive, while jitter describes variation in delay. Their effect depends on the task and conditions; a traffic chart alone does not explain an application. Microsoft’s network testing guidance shows why consistent test conditions and separate latency and capacity measurements matter.

High utilisation may point to congestion, but it is not proof. More capacity can help when the measured link is the constraint. It may not help when the delay lies in Wi-Fi, another part of the path or the application itself.

Low traffic does not rule out a problem either. Compare the work that staff must complete, rather than treating a faster speed test as the acceptance test. For a wider investigation, see our guide to finding the cause of a slow cloud application.

Prepare evidence for a focused investigation

Give your provider a short record of the task, locations and times affected. Include the relevant reports, calculations and task results. State what the measurements cover and what they cannot show.

If the slowdown did not occur during the observation period, say so. A useful baseline can guide another test, but it does not establish a cause that was never observed.

CleverSpeed’s Branch Application Performance Assessment starts with a proposed scope of one application, one business task and up to two locations. Confirm feasibility, observation period, access, test conditions and fee before work begins.

Discuss a baseline, findings that separate supported explanations from open questions, and a prioritised action plan. Agree who handles each next step. The assessment does not require an Edge Relay purchase, and a different traffic path is tested only where suitable.

Assessment, implementation and ongoing service are separate matters to agree. Review the scope and pricing approach, including any monitoring or response coverage, before committing.

Common questions about office network traffic

Can a laptop measure the whole office’s bandwidth usage?

No. Its adapter statistics describe that device’s interfaces. Use an authorised report for the relevant office connection when you need the wider view.

Which time window should we use?

Cover the reported slowdown and a comparable normal period. Keep the task, sampling interval and conditions consistent where possible. Note any differences rather than hiding them inside an average.

Does a busy link prove why an application is slow?

No. Match the traffic readings with task completion, latency and loss. High utilisation can be a useful clue, but other parts of the path or application may need investigation.

What evidence should we share with our IT provider?

Share the task, locations, observation times, report scope and units. Add relevant calculations and task results, with any gaps or resets. Be clear if the problem did not appear during testing.

Discuss the next step

Still unsure why an application slows down? Tell CleverSpeed which task is affected, where it happens and what you have measured.

For practical network and edge guidance, subscribe to the CleverSpeed newsletter. Get help measuring performance, improving reliability and making informed infrastructure decisions.