When the Internet
feels slow.

01 / Identify the scope

What is actually slow?

Start with the experience, not an assumption about the cause. Note when it began and whether it is constant or comes and goes.

• One device or several? Compare another computer in the same location if one is available.
• One application or many? Check whether the issue affects a single website, a cloud application, video meetings, or multiple services.
• One location or the whole office? Note affected rooms, floors, or sites.
• Upload, download, or responsiveness? A slow file upload, a delayed page, and a choppy call can point to different conditions.

02 / Compare the connection

Is it Wi-Fi or wired too?

If a suitable wired connection is already available, compare a wired computer with an affected Wi-Fi device. Keep the comparison as similar as practical: same application, destination, and time.

If only Wi-Fi is affected, investigate wireless coverage, interference, the access point, and the client device. New York City buildings often have many nearby Wi-Fi networks and other wireless devices sharing the air. Their activity, along with walls, distance, and the number of connected devices, can affect wireless performance and make it difficult to reach the full speed of an Internet service. The effect varies by location and conditions.

If both wired and Wi-Fi devices are affected, the cause could still be inside the office or elsewhere. Neither result alone identifies the fault.

Check the wired adapter’s negotiated speed. A 1 Gbps adapter, for example, cannot measure the full capacity of a 10 Gbps circuit. Use a device and interface suitable for the service being tested.

03 / Look for context

What changed?

Ask whether the issue began after a configuration change, a software update, a new device, or a change in the office network. Also check for large backups, file transfers, or other activity that might be using capacity.

Look for visible power or link warnings without disturbing equipment. Record what you see and share it with your IT team or support. Don’t disable security controls or alter router, firewall, or DNS settings as a first troubleshooting step.

04 / Measure carefully

Use a speed test as one observation.

A browser test such as Speedtest.net can provide a quick comparison. Select a known server where possible and record the server, time, download, upload, and latency. Test from a suitable wired device if practical.

Repeat a test when the issue occurs and, if useful, at a quieter time. Tests can use substantial bandwidth and compete with business traffic, so coordinate before running high-speed or repeated tests. A low result does not by itself identify the cause or prove a circuit fault.

Results are affected by the device, adapter, operating system, network equipment, test server, and path. A test run on the same machine as the server may use a local path and is not an external circuit test.

05 / For IT teams

Tools that help narrow the path.

Use destinations you are authorized to test. Save results with timestamps, the source and destination, and the protocol used. Avoid sending passwords, tokens, or other sensitive information with a support request.

For iperf3, test only a server you operate or are authorized to use. Stealth’s example endpoint is iperf3.stealth.net. A parallel test such as iperf3 -c iperf3.stealth.net -P 8 -t 10 sends traffic toward the server; add -R to test the reverse direction. The server may be busy. Parallel performance is not the same as the performance of one connection.

For high-speed measurements, check both test hosts, their interfaces and CPU, the network path, and operating-system settings. Avoid changing production settings based on one result.

06 / Interpret the evidence

A symptom is a starting point.

High latency under load can indicate queueing somewhere in the path; low throughput can also result from endpoint, server, or transport limits. A test to one destination does not establish the performance of every destination.

If one application is affected while others work, share the application, destination, and examples with support. The cause could be the application, its network path, local policy, or another condition. Avoid attributing the issue to a particular provider or router without supporting evidence.

07 / Get help

What to send support.

• Your company, service address, and a callback number.
• When the issue began, the time zone, and recent examples.
• Who or what is affected: devices, applications, floors, or sites.
• Whether wired and Wi-Fi devices are affected, if you have compared them.
• Relevant test results, including timestamps, destinations, and directions.
• Any recent changes or visible equipment warnings.

Stealth support is available around the clock at +1 212 232 2020 and support@stealth.net. Please leave passwords, API keys, and private credentials out of your message.