A troubleshooting methodology that stops the guessing

"The Wi-Fi is slow" is not a fault report. This is how to turn it into one.

Step 0: define the problem precisely

Get answers before you touch anything:

Who — one user, one device type, one team, everybody?
Where — one room, one floor, one building, everywhere?
When — constantly, at 09:00, during the all-hands, since Tuesday?
What — one application, all applications, connecting, staying connected, throughput?

The four answers usually narrow the cause to one category before you have opened a single tool.

The categories, and what they look like

Symptom pattern	Likely cause
Everyone, everywhere, at once	Not Wi-Fi. DHCP, DNS, RADIUS, WAN or upstream.
One location, all users	Coverage hole, interference, or a failed AP.
One device type	Client driver, roaming behaviour, band or DFS support.
Busy periods only	Capacity — channel utilisation, not coverage.
Roaming or moving users	Sticky clients, roaming configuration, insufficient overlap.
Slow but strong signal	SNR, retries, or airtime consumed by others.

Step 1: prove it is Wi-Fi

Test on a wired connection at the same location. If it is also bad wired, you have saved yourself a day. This step is skipped constantly and it is the single most valuable thing on this page.

Step 2: look at the right metrics

In order of usefulness:

Channel utilisation. Above 50 percent, expect complaints; above 70 percent, expect anger. This one number explains most "slow Wi-Fi".
Retry rate. Above 15 percent indicates interference or a marginal link.
SNR, not RSSI. A strong signal in a noisy channel performs badly.
Client data rate / MCS. A client sitting at MCS 2 at close range tells you something specific is wrong.
Roaming events per client. Excessive roaming means overlap is too aggressive or thresholds are wrong; zero roaming while walking means clients are sticky.

Step 3: capture, do not guess

Spectrum analyser for non-Wi-Fi energy. If channel utilisation is high but your APs are not transmitting much, something else is using the air — and no amount of Wi-Fi configuration will fix a leaky microwave, a video sender or a faulty ballast.
Packet capture in monitor mode, on the correct channel and width, from a device near the affected client — not from the AP, and not from a laptop in the comms room. Look for retries, deauthentications, and the reason codes attached to them.
Client-side logs. macOS wireless diagnostics, Windows WLAN reports, and Android Wi-Fi logs all give roam and disconnect reasons the infrastructure never sees.

Common causes, ranked by how often they turn out to be the answer

Capacity, not coverage. Too many clients and too few channels, usually made worse by channel widths that are too wide.
Sticky clients. A device clings to a distant AP at -80 dBm rather than roaming. Fix with minimum basic rates, correct cell sizing and 802.11k/v — not by turning power up.
A single misbehaving client. One legacy device transmitting at 1 Mbps consumes an astonishing amount of airtime. Find it by data rate, not by complaint volume.
Non-Wi-Fi interference. Especially in 2.4 GHz, especially in warehouses, kitchens and hospitals.
Upstream infrastructure. DHCP pool exhaustion and slow RADIUS both look exactly like "Wi-Fi is broken" to a user.
A firmware regression. Both AP and client. Note what changed and when — the timeline usually gives it away.
Physical change. New racking, a new partition wall, a rearranged office, a metal-lined meeting pod dropped into an open-plan floor.

What not to do

Do not raise transmit power to fix a coverage complaint. You will make roaming and co-channel contention worse and the client still cannot shout back.
Do not add an AP before measuring channel utilisation. If the channel is congested, another AP on the same channel makes it worse.
Do not change five settings at once. You will fix it and never know which change did it, which means you will not be able to fix it next time.
Do not trust the client's signal-strength indicator. Bars are a marketing feature.