How to Diagnose Slow Office Internet: A Layered Runbook

“The internet is slow” describes an experience, not a root cause. The bottleneck may be one device, Wi-Fi coverage, a switch port, security inspection, DNS, the provider path, a cloud service, or an application. A layered runbook narrows the fault domain quickly and avoids expensive guesswork.

Triage the scope

• One user, device, application, floor, site, or everyone.
• All day, peak period, intermittent, or after a known change.
• Wired, Wi-Fi, VPN, remote, or every connection.
• Download, upload, voice, video, authentication, or a specific transaction.
• Expected result and a reproducible test.

Check the endpoint and local network

Inspect resource pressure, driver and firmware state, local security tools, VPN routing, and background synchronization. Compare a known-good wired device. For Wi-Fi, measure signal, interference, channel utilization, retries, roaming, and access-point load rather than relying only on the displayed signal icon.

Measure the service path

Review switch errors and utilization, firewall health and inspection load, DNS response, latency, jitter, packet loss, route changes, and TCP throughput. Test during affected and unaffected periods. Do not assume a clean access-link result proves the cloud application or its full end-to-end path is healthy.

Escalate and close with evidence

Provide the carrier or vendor with timestamps, source and destination, test method, path observations, affected transactions, and comparison results. Keep current network diagrams and ownership consistent with CISA’s Cybersecurity Performance Goals. After a change, repeat the original test and monitor recurrence before closure.

Next step for your environment

Create a short incident template and use it on the next slowdown instead of beginning with a circuit upgrade.

Record the accountable owner, baseline, source date, decision, exceptions, acceptance evidence, and review trigger. Test consequential changes in a bounded environment, maintain a rollback path, and verify the real result before closing the work. Product names, availability, pricing, legal requirements, and security guidance can change; recheck the primary sources whenever the decision is renewed or the environment changes.

If you need an independent baseline before changing production systems, start with an ITECS technology and security assessment and keep the resulting evidence with the decision record.

Sources and update trigger

• IETF — RFC 6349: Framework for TCP Throughput Testing
• CISA — Cybersecurity Performance Goals

Review trigger: Review after network, application, provider, security, device, Wi-Fi, office, or troubleshooting-tool changes.