Diagnosing "it's slow" on a workstation: Wi-Fi, Teams, site link

"It's slow" is one of the most frequent tickets, and one of the vaguest. Behind it there may be a saturated workstation, weak Wi-Fi, an overloaded gateway, a full Internet link, slow DNS or a service down at the vendor. The method: start from the workstation and work up link by link, to the first one that fails.

#1. Pin down the complaint

Before any measurement, ask four questions:

1. What? One application, all of them, only the Internet, Teams calls, shared files?
2. When? Since when, at what time, all the time or now and then?
3. Where? At the office or working from home, on Wi-Fi or wired, on which site?
4. Who else? One person, a whole floor, a whole site?

If a whole site complains at the same time, start with the site link (step 5). If only one person complains, start with their workstation.

#2. The workstation

Open Task Manager while the slowness is happening. A processor above 90 %, full memory or a disk busy at 100 % explain many complaints, without the slightest network problem. An application that is "not responding" feels just like a slow network.

Timing matters. A measurement taken an hour after the complaint often shows nothing any more: the slowness was passing, and that is what you needed to see.

#3. Wi-Fi

netsh wlan show interfaces

Read the signal, the band (2.4 or 5 GHz), the channel, the receive and transmit rates, and the access point address (BSSID). On recent versions of Windows 11, displaying the network and the access point may require allowing access to location.

Three causes come up often:

• the workstation stays attached to a distant access point while another one is closer;
• the network is broadcast only on 2.4 GHz, a narrow and crowded band;
• the access point is saturated, by too many clients or by a channel shared with the neighbours.

The last one can only be seen from the Wi-Fi controller, not from the workstation.

When working from home, the home router and Wi-Fi are part of the workstation from the helpdesk's point of view. A network cable for the time of a test often settles the question.

#4. The local network and DNS

Get-NetIPConfiguration | Select-Object InterfaceAlias, IPv4DefaultGateway, DNSServer
ping -n 50 <gateway address>
Measure-Command { Resolve-DnsName www.exemple.fr -Server <DNS server address> } | Select-Object TotalMilliseconds

On a healthy local network, the gateway answers within a few milliseconds and loses no packets. Losses towards the gateway point to the Wi-Fi or the cabling. A slow gateway points to an overloaded device. A DNS resolution that takes several seconds slows down every page, while bandwidth is intact.

If the workstation uses a VPN, repeat these measurements with the VPN off, then on. A VPN that sends all traffic through head office adds head office's latency to every web page.

#5. The site link

pathping -n www.exemple.fr

pathping measures losses at each hop for a few minutes. Losses that start at the operator's first router and continue afterwards point to the link. Losses on a single intermediate hop, with nothing after it, are often harmless: some routers answer probes sparingly.

A full link gives the same symptoms as a broken one. Look on the site's router or firewall for what is consuming it: a backup started during the day, updates downloaded by every workstation at the same time, a file synchronisation. On a site with a 4G or 5G backup link, also check that the main link has not gone down.

#6. Teams and calls

A call copes badly with packet loss and jitter, even with good bandwidth. Microsoft publishes network targets for Teams: around 100 ms round trip, less than 1 % loss and less than 30 ms of jitter. The Teams admin center gives, for each user, an analysis of their recent calls.

The useful question: did the call degrade at the same time as the workstation or its network? If so, the cause is local (Wi-Fi, workstation, gateway). If the workstation was fine, look towards the Internet or Microsoft.

#What FirstSI brings

The hardest part of diagnosing slowness is being there at the right moment. NetDiag measures the workstation about every 15 seconds, continuously, and at each measurement names the first link that failed, in the order of this guide: Workstation, LAN, Local infra, Internet, DNS, Service.

1. Open NetDiag → Network diagnostics (#/netdiag).
2. In Select a workstation, type the workstation's name or the person's name.
3. With Jump to, centre the timeline on the time given in the ticket.
4. Read Causes of anomalies: it is often the line to paste into the ticket.

The diagnostic report (PDF) can be attached to the ticket as is: summary, timeline, charts, Teams calls. See NetDiag: workstation network diagnostics.

For a whole site, NetworkMonitor raises an alert when the latency of a tunnel or WAN link exceeds 100 ms for 5 minutes, or its loss 5 % (default thresholds). See NetworkMonitor: sites, devices, tunnels. If the site depends on an operator line, the WAN gateway reads its status in the operator's customer area.

Ticket pre-diagnostics does part of this work as soon as a "Network" ticket arrives: it checks NetDiag and the tunnels before the technician does.

#Further reading

• Flow explorer: who is using the site link, towards which country and for which service.
• AI assistant: asking the question in plain language, about a workstation or a site.
• Investigate a device: everything FirstSI knows about an IP address or a workstation name.

Overview: Wi-Fi and Teams diagnostics for workstations↗

Source: · FirstSI Docs · updated 2026-10-11