If a site seems slow or unreachable, ping tells you whether a host responds and how long round trips take, and traceroute (tracert on Windows) shows you the network path packets take to get there, hop by hop. Run ping first. If it fails or times out, run traceroute to find where the path breaks down.
Both are diagnostic tools, not fixes. They tell you where a problem lives (your network, an intermediate provider, or the destination server) so you know who needs to act.
Using ping
Open a terminal (macOS/Linux) or Command Prompt (Windows) and run:
ping yourdomain.com
On Linux and macOS this runs until you stop it with Ctrl+C. On Windows it stops automatically after 4 packets, or you can limit it manually with ping -c 4 yourdomain.com (macOS/Linux) or ping -n 4 yourdomain.com (Windows).
Each line reports a round-trip time in milliseconds:
- Replies with low, consistent times (a few ms on a local network, tens to low hundreds of ms across the internet) mean the connection is healthy.
- Request timed out or 100% packet loss means packets aren't reaching the host, or its replies aren't coming back. This can also mean the destination is blocking ICMP (the protocol ping uses) rather than actually being down, so don't treat a failed ping alone as proof a site is offline. Confirm with a browser or
curl -I yourdomain.combefore assuming there's an outage. - Unknown host or could not find host means DNS resolution failed. The name isn't resolving to an IP at all, which points at a DNS problem rather than a network or server problem.
If you get "unknown host," check where your domain's DNS actually lives. If your domain uses our nameservers, records are managed in the portal under Services > your hosting > DNS Zone Editor. If you just changed a record, give it time to propagate. You can flush your local resolver cache while you wait, which clears out stale cached answers on your own machine (it won't speed up propagation elsewhere).
Using traceroute
On macOS and Linux:
traceroute yourdomain.com
On Windows, the equivalent command is:
tracert yourdomain.com
Both print a numbered list of routers (hops) between your machine and the destination, with round-trip times for each. Read it top to bottom:
- Times climb steadily and reach the destination at the last hop. Normal. Some latency increase per hop is expected since you're crossing more distance and more networks.
- A hop shows
* * *(three asterisks). This means that router didn't respond to the probe, which is common and often not a problem. Many routers are configured to ignore or deprioritize traceroute probes for security reasons, while still forwarding your real traffic fine. Only worry if the trace never recovers and dies completely a few hops later. - The trace stops dead and never reaches the destination. This points to a break in the path: a routing issue at an intermediate network, or the destination host actually being unreachable.
- Latency spikes at one specific hop and stays high for every hop after it. That hop is where the slowdown is introduced. If it's inside an intermediate ISP's network, there's nothing to configure on your end or on the server; it's usually transient and clears on its own.
Traceroute is most useful for telling the difference between "my internet connection is fine but something between me and the server is congested" and "the problem is local to my network." It rarely points at something you can fix directly, since most hops belong to networks neither you nor we control.
Shared hosting vs VPS: what you can actually act on
On most hosting accounts, ping and traceroute are client-side tools you run from your own computer to diagnose what you're seeing. If both come back clean but the site still won't load in a browser, the issue is more likely at the application or DNS level, not the network path, and checking your hosting resource usage is a good next step (a site that's hit its process or resource limits can behave like it's unreachable).
On a VPS, you have root SSH access, so you can run these same tools from the server outward too, which helps isolate whether a problem is on your visitors' side or your server's outbound path. You can also test from inside the server whether it can reach external resources (a database host, an API you depend on, a package repository) using the same two commands.
When to open a ticket
If traceroute shows the path dying at or just before the last hop (the point closest to us), or if ping to your domain fails while ping to other, unrelated sites works fine from the same network, that's worth reporting. Open a ticket from Support in the portal and include the full output of both commands so support can see exactly where the path broke.