Start with a specific question
“The internet is down” can describe several different problems: a device may have lost its local connection, a name may not resolve, packets may not reach a server, or a particular application may be unavailable. Ping and traceroute help narrow the possibilities, but neither is a complete test of a website or service.
Before testing, note what fails and what still works. Can you reach other sites? Does the problem affect one device or everyone on the same network? If you are testing a hostname, also try a known IP address that you are permitted to contact. A hostname failure paired with a successful IP test points toward name resolution as a possibility; failures to both suggest looking elsewhere. Use the same destination across tests so the results are easier to compare.
Use ping to check replies and delay
Ping sends small probe packets and reports whether replies arrive. On many systems, it uses ICMP echo requests. For a short test on macOS or Linux, run “ping -c 4 example.com”; on Windows, run “ping -n 4 example.com”. The summary usually shows how many probes were sent and received, whether any were lost, and round-trip times for the replies.
If replies arrive, your device can exchange these probe packets with the destination at that moment. A high or inconsistent round-trip time may help explain sluggishness, particularly if it appears repeatedly while the problem is happening. Packet loss deserves a closer look, but a handful of probes is not enough to establish a persistent pattern. Repeat the test and compare it with a nearby destination, such as your network’s default gateway, if you know its address.
No ping reply does not prove that a host is offline. Firewalls and servers may block or ignore probes while still serving web traffic. Conversely, a successful ping does not prove that a website, login, or application works: those services use other protocols and may fail independently.
Use traceroute to inspect the path
Traceroute probes a destination with gradually increasing hop limits. Routers where a probe’s limit expires may send a response, allowing the tool to display successive hops and their response times. Run “traceroute example.com” on macOS or Linux, or “tracert example.com” on Windows. The tools can use different probe types depending on the operating system and settings, so their output may differ even for the same destination.
A line of asterisks or timeouts means that hop did not provide a usable reply to those probes. It does not necessarily mean traffic stopped there: if later hops respond, packets continued beyond it. Routers may limit or deprioritize replies to diagnostic probes, and firewalls may filter them. Likewise, an unusually slow intermediate hop is not strong evidence of a bottleneck if subsequent hops and the destination respond promptly.
Network paths can change between probes, and replies may travel back by a different route. Treat the displayed hops as clues, not a perfect map. If the trace reaches the destination, that supports basic reachability for the probe type used. If it ends early, compare it with traces to other destinations before deciding where a problem lies.
Work from your device outward
A useful sequence begins close to home. First, check that your device is connected to the intended network. Then ping your default gateway, if one is shown in your network settings. If that fails while other devices can reach the gateway, investigate your device, Wi-Fi signal, cable, or local network settings. Next, test a destination beyond your local network, followed by the hostname or service you actually need.
If the gateway responds but outside destinations do not, traceroute can show how far probes appear to get. Compare more than one destination and, if possible, test from another device on the same network. When only one hostname fails, check whether it resolves to an address; ping and traceroute cannot diagnose every DNS issue on their own. When only one application fails despite successful network probes, examine that application’s settings or service rather than assuming the network path is broken.
Record the destination, approximate test time, commands, and results when asking a network administrator or provider for help. Include what you expected to work and whether other devices are affected. A trace may expose internal hostnames or network addresses, so review it before posting it publicly. Used together, ping and traceroute are most valuable for narrowing a question—not for declaring a single hop or organization at fault.
