A slow network rarely announces itself as a single, obvious fault. It starts with delayed cloud applications, choppy calls, files that take too long to open, or staff reporting that “the internet is down”. A structured network performance troubleshooting checklist prevents guesswork, helps protect business continuity and gives teams a clear route from symptom to cause.
For a small or mid-sized organisation, the aim is not simply to make a connection appear faster. It is to establish whether the problem sits with a user device, Wi-Fi coverage, switching equipment, the broadband circuit, a cloud platform or a security control. The right response depends on the evidence.
Start by defining the business impact
Before restarting equipment, establish what is actually affected. Ask whether the problem applies to one person, one department, one office area or every user. Identify when it began, whether it is constant or intermittent, and which services are slow.
This matters because a poor Microsoft 365 experience does not automatically mean the internet connection is at fault. A single user with poor performance may have a failing Wi-Fi adapter, an overloaded laptop or a local configuration issue. If everyone is affected, the focus should shift towards shared infrastructure, internet connectivity, core network equipment or a third-party service.
Capture a short record of the incident: affected users and sites, applications involved, approximate start time, error messages, recent changes and whether wired users experience the same issue as wireless users. This information makes escalation faster and avoids repeating basic checks.
Network performance troubleshooting checklist
Work through the following checks in order. Begin with the least disruptive tests and only make configuration changes once there is evidence to support them.
1. Confirm the scope of the fault
Compare the experience across different devices, locations and connection types. Test a known-good laptop on both Ethernet and Wi-Fi. If a wired connection performs normally but Wi-Fi is slow, the issue is unlikely to be the broadband line. If users at multiple sites report the same cloud application failure, investigate the supplier’s service status and your WAN or DNS configuration before replacing local hardware.
It is also worth separating internal and external performance. If files stored on an on-premises server open slowly while web browsing is normal, the fault may lie with the local area network, server storage or authentication services rather than internet bandwidth.
2. Check for obvious physical and power issues
Physical faults remain a common cause of intermittent network problems. Inspect network switches, firewalls, wireless access points and internet routers for warning lights, unexpected restarts, excessive heat or failed power supplies. Confirm that cabinets are ventilated and that critical equipment is protected by an appropriate uninterruptible power supply.
Check patch leads and uplink cables where a specific desk area, switch or access point is affected. Damaged cables, loose connectors and poorly terminated runs can cause packet errors and link-speed negotiation problems. Replacing a suspect patch lead is a sensible test. Rebooting core equipment without a plan is not, particularly during business hours.
3. Measure latency, packet loss and bandwidth
A speed test alone is not a complete diagnosis. Download and upload figures can look acceptable while video calls remain unreliable because of high latency, packet loss or jitter. Measure performance at the firewall or router, then compare it with tests from a wired user device and a wireless device.
High latency can point to an overloaded connection, a routing issue or a distant cloud service. Packet loss often indicates a circuit fault, a congested link, failing hardware or Wi-Fi interference. Jitter is especially damaging for voice and video, where packets need to arrive at a consistent rate.
Record results at different times of day. A problem that occurs only at 09:00, lunchtime or during backup windows may be capacity-related. One that appears after heavy rain, construction work or a power event may require investigation by the connectivity provider.
4. Review internet circuit utilisation
Examine firewall and router monitoring to see how much of the available connection is in use. Persistent utilisation close to the circuit limit can make all services feel slow, particularly if large uploads are consuming upstream bandwidth. Cloud backups, synchronisation tools, software updates and large file transfers are common causes.
The remedy is not always a bigger circuit. Traffic prioritisation, scheduled backups and sensible application controls may solve the immediate issue at a lower cost. However, an organisation that has grown its cloud use, remote access or VoIP estate may simply have outgrown its existing connection. Capacity planning should be based on normal peak demand, not a quiet-period speed test.
5. Investigate Wi-Fi separately
Wireless networks need their own assessment. Coverage, signal strength, channel overlap, access point density and client numbers all affect performance. A strong signal does not guarantee a good user experience if too many devices are competing for airtime on the same access point.
Check whether access points are positioned appropriately and not obstructed by metal cabinets, dense walls or equipment rooms. Review channel planning, especially in busy offices or multi-tenant buildings where neighbouring networks can create interference. The 2.4 GHz band offers longer range but is often congested; 5 GHz generally provides better capacity, while 6 GHz may suit compatible modern equipment in the right environment.
Avoid treating Wi-Fi complaints as an internet issue without testing a wired connection first. Equally, do not assume more access points will fix poor wireless service. Poorly placed or badly configured access points can increase interference rather than improve capacity.
6. Check switching, routing and firewall health
Managed switches and firewalls provide useful evidence when performance degrades. Look for interface errors, discarded packets, unusually high CPU or memory use, ports operating at the wrong speed, loops, broadcast storms and saturated uplinks.
Network loops can be particularly disruptive. They may arise when an unmanaged switch is connected incorrectly or when redundant links lack suitable loop protection. Symptoms can include widespread slowness, devices dropping off the network and switch activity lights flashing continuously.
Firewall inspection features can also affect throughput. Web filtering, intrusion prevention, VPN encryption and deep packet inspection provide valuable protection, but they consume processing capacity. If a firewall is consistently under strain, disabling security services to regain speed creates an unacceptable risk. Review the configuration, firmware level and hardware capacity instead.
7. Verify DNS, DHCP and authentication services
Users often describe a DNS problem as “the internet is slow” because websites and cloud services take too long to start loading. Test whether systems can reach a known IP address while name-based access fails or is delayed. Review DNS forwarders, filtering services and local DNS server health.
DHCP faults may cause devices to lose connectivity, receive an incorrect address or fail to join the network after moving between offices. Check address pool capacity, lease settings and conflicting scopes. For domain-connected devices, slow logons and file access may also indicate an issue with Active Directory, time synchronisation or authentication paths.
8. Consider recent changes and external dependencies
A disciplined change record is invaluable during troubleshooting. Check for recent firewall rule changes, Wi-Fi configuration updates, new cloud backup jobs, endpoint security deployments, ISP work, office moves or newly connected devices. A change is not automatically the cause, but timing should be investigated rather than dismissed.
External dependencies deserve the same scrutiny. Check the status of internet service providers, cloud applications, VoIP platforms and secure access services. Where possible, test from an alternative connection such as a managed mobile connection. This helps distinguish a site-specific network issue from a wider supplier outage.
When to escalate the issue
Escalate quickly when the fault affects critical services, multiple users, security controls or more than one site. Preserve logs, timestamps, monitoring screenshots and test results before making major changes. This gives an IT support provider, ISP or software supplier the evidence needed to act without restarting the investigation from the beginning.
For recurring issues, move beyond incident resolution. Trend monitoring can reveal whether the cause is ageing hardware, insufficient bandwidth, poor wireless design, an unsuitable firewall specification or unmanaged growth in cloud traffic. A stable network is maintained through visibility and planned improvement, not emergency fixes alone.
A practical checklist gives staff a calm, repeatable response when performance drops. If the same warning signs keep returning, treat them as a capacity or design question – and resolve the underlying risk before it becomes a longer outage.