How to Diagnose Packet Loss on a Small Business Network
Packet loss can make cloud apps stall, calls break up, and remote sessions freeze, even when the internet connection appears to be online. A structured packet loss troubleshooting process helps you find whether the issue affects one device, the local network, or the connection beyond your office.
Start by comparing devices, then test the local network, gateway, and internet path as separate segments. Keep a record of what you observe before changing settings, since a quick reset can erase clues about the cause.
Start by defining the problem
First, identify what users experience and when it happens. Packet loss often appears as choppy VoIP audio, slow file transfers, video meetings that freeze, or brief disconnects from hosted applications. Those symptoms can also come from latency, jitter, DNS failures, or an application problem, so treat them as clues rather than proof.
Find out who and what is affected
Ask whether the issue affects one person, several devices, one application, or the whole office. Note whether impacted users are on Wi-Fi, wired Ethernet, or a VPN. If only one cloud service fails while other sites work, the cause may lie with that service or its route rather than the entire network.
Record the time, device name, location, connection type, affected service, and any error message. Include whether the problem happens continuously or only during busy periods. This gives your IT support team a useful starting point.
Check for recent changes
A new switch, access point, firewall rule, cable move, software update, or internet provider change can help explain when the problem began. Ask whether symptoms started after a change, but don't assume the timing proves cause and effect. A recurring pattern at certain times may point to congestion or wireless interference.
Compare devices before testing the network
Compare at least two affected devices with one that works normally. Ideally, test them near the same time and using the same application. If several devices on one Wi-Fi access point report trouble while wired computers work, focus first on wireless conditions. If both wired and wireless devices are affected, look beyond a single access point.
When possible, test the same laptop over Ethernet and Wi-Fi. A clean wired test alongside a poor wireless test narrows the focus to the wireless connection, though it doesn't identify the exact cause. A faulty cable, access point, client device, or configuration can produce similar symptoms.
Pay attention to location and movement. Complaints concentrated in one room can indicate weak coverage or interference. Problems that follow a user's laptop across the office may point to the device, its network adapter, or software. Repeated wireless complaints can also reflect channel interference or limited capacity, not necessarily a failed access point. See our business Wi-Fi coverage survey guide for factors that affect office wireless performance.
Test the local network and gateway
Test one network segment at a time. Begin with another device on the same local network, then test the default gateway, usually the firewall or router. These checks help separate a device-to-device or Wi-Fi issue from a problem at the network boundary.
Test a local device
If you have an authorized, responsive computer or server on the same network, ping its local IP address from the affected device. First confirm that both devices are on the same network or VLAN. Firewalls and client-isolation settings can block ping, so no reply doesn't always mean packets are being lost.
If one device cannot reach a local peer but another can, compare their connection method, network settings, and location. On a wired system, inspect the cable connection and link lights without unplugging shared equipment. A support technician can review switch-port error counters, such as CRC errors or discards, if the problem continues.
Test the gateway
Find the default gateway in the device's network details. On Windows, run ipconfig /all
; on Linux, use ip route
. On macOS, run route -n get default
. The gateway address varies by network, so use the address shown on the affected device.
Then send a short series of pings to that address. For example, Windows uses ping -n 50 192.168.1.1
, while macOS and Linux use ping -c 50 192.168.1.1
. Replace the sample address with your actual gateway.
If gateway pings show loss while other devices remain stable, focus on the device's connection, local cabling, Wi-Fi, or gateway. However, some routers limit responses to ping. Compare with another device and with the user's actual symptoms before drawing a conclusion.
Test the internet path separately
If the local peer and gateway respond consistently, test beyond the office network. Ping a public IP address such as 1.1.1.1
, then compare the results with a second destination. A single remote target may have its own response limits, so repeated, consistent patterns matter more than one result.
A public IP test avoids relying on DNS to find the destination. Separately, run nslookup microsoft.com
to see whether DNS can resolve a domain. If an IP address responds but name lookups fail, investigate DNS rather than treating the result as confirmed packet loss.
Trace the route when needed
Windows includes tracert
, and macOS and Linux include traceroute
. For example, tracert -d 1.1.1.1
on Windows and traceroute -n 1.1.1.1
on macOS or Linux can show the route toward a destination. Windows also offers pathping -n 1.1.1.1
, which gathers repeated information over time.
A hop that doesn't reply isn't automatically a failure. Routers may ignore or limit diagnostic traffic while forwarding normal traffic. Loss that appears at one hop and continues through later hops is more concerning than loss reported only at an intermediate hop. These tools help narrow the path, but they don't by themselves prove which device or provider is responsible.
Read the results in context
Compare packet loss across the affected device, another device, the gateway, and at least two internet destinations. If the device loses packets to the gateway, investigate the local connection first. If the gateway is stable but multiple outside targets show loss, the issue may be on the WAN connection or farther along the provider route.
Keep the test times aligned. A short test during a quiet period may miss a problem that occurs when the office is busy. Run checks while users see the issue, and repeat them later to see whether the pattern changes.
Ping tests use ICMP, and some devices handle that traffic differently from ordinary application traffic. Therefore, a clean ping doesn't prove every application path is healthy, and a ping with some missing replies doesn't prove the network is unusable. Compare command results with actual service behavior, such as a call, VPN session, or cloud application.
Check common causes without changing settings
Local loss can come from a damaged cable, loose connection, failing switch port, wireless interference, or an overloaded access point. On a switch, errors or a port that repeatedly changes link state can be useful clues. On Wi-Fi, signal strength is only one part of performance. Interference, client count, roaming, and capacity can also affect the connection.
Loss beyond the gateway may coincide with a saturated internet upload, a provider fault, or a failing modem or firewall. A WAN link can show as connected while users still struggle to reach Microsoft 365 or other hosted services. If calls are affected, compare voice symptoms with other traffic. Correct traffic-priority settings don't prevent loss caused by a full upload queue, switch errors, or provider trouble. Our guide to VLAN design for secure guest Wi-Fi and VoIP covers why call quality depends on the whole route.
Avoid treating a speed test as a packet-loss test. It measures throughput under its test conditions, while packet loss requires separate observation. Also, don't change firewall rules, QoS settings, VLANs, or router configurations as a first response. Unplanned changes can affect other users and make the original problem harder to diagnose.
Take safe next steps and escalate
Save command output or write down the results, including device, connection type, destination, time, and loss reported. Note whether users were actively experiencing trouble during each test. If the issue affects multiple employees, business-critical applications, or several network segments, involve your IT support provider before adjusting shared equipment.
If a cable is visibly damaged or disconnected, report it to the person responsible for network changes. Avoid rebooting the modem, firewall, or switch before recording the issue. A restart may temporarily clear symptoms while removing useful logs or disrupting other services.
Contact the ISP when local devices and the gateway appear stable, but several external destinations show loss during the same period, especially if multiple wired users are affected. Share timestamps, affected services, and test results, and ask the provider to investigate the circuit. If only one destination has trouble, include that distinction rather than reporting a general outage.
Contact a network professional when results vary by switch, access point, VLAN, or device, or when you see repeated port errors, configuration changes, or widespread service impact. For VoIP issues, document call times and whether the problem affects inbound, outbound, or internal calls. The small business VoIP reliability checklist offers related guidance for assessing call performance.
Monitor patterns and keep useful records
A single test captures a moment; monitoring helps reveal recurring patterns. Track packet loss, latency, jitter, bandwidth, interface errors, and link status over time. Break bandwidth down by office, application, or device group when your monitoring tools support it. Sustained increases may coincide with business growth, cloud backups, or unexpected traffic.
Set useful alerts for critical device or circuit failures, and account for planned maintenance so routine work doesn't create false alarms. Avoid duplicate notifications when one failed switch causes many connected devices to report offline. Reviewing trends monthly can help identify recurring trouble before it disrupts another workday. See our network monitoring checklist for small businesses for performance and alerting considerations. SJC Technology offers 24/7 network monitoring services.
Key Takeaways
- Compare affected and unaffected devices before assuming the ISP is at fault.
- Test a local peer, the gateway, and internet destinations separately.
- Use ping and route-tracing tools as evidence, not as definitive proof of a fault.
- Record times, targets, connection types, and user symptoms before making changes.
- Escalate persistent, widespread, or business-critical issues to your IT provider or ISP.
Frequently Asked Questions
Does any packet loss mean the network is broken?
No. A few missing ping replies may reflect how a router handles diagnostic traffic rather than a failure affecting applications. Look for repeatable loss that aligns with real user symptoms, and compare results across devices and destinations.
Why does Wi-Fi show loss when Ethernet works?
The wireless path adds variables such as signal strength, interference, roaming, and the number of connected clients. A wired comparison helps narrow the problem, but it doesn't identify which wireless factor is responsible.
What details should I give IT support or my ISP?
Share when the issue occurred, who and what was affected, whether devices used Wi-Fi or Ethernet, and which destinations you tested. Include gateway and outside test results, DNS lookup results if relevant, and any recent network changes.
Diagnose One Segment at a Time
Packet loss troubleshooting works best when each test answers a specific question. Compare devices, test the LAN and gateway, then examine the internet path while symptoms are occurring.
A clear record helps your IT team or ISP focus on the right segment instead of guessing. That makes the next step safer and more useful for the business.