Using the Enterramon Ping Tool
What is ping
Ping is the oldest, simplest diagnostic on the internet, and it still does its one job well. It sends a small packet to a target, an IP address or a domain, and waits to see if and how fast something answers back. The name comes from sonar, and the idea is basically the same, send a signal out, time how long it takes to come back, and use that round trip to work out how far away and how responsive the thing on the other end is.
We built our Ping Test around that same idea, just with a bit more structure around it. Pick a target, choose a region to test from, choose IPv4 or IPv6, and we send ten packets from that region to the target and time each one individually, not just the average.
Using the Enterramon Ping Tool
Head to enterramon.com/ping-test and enter a domain name or IP address. No https://, no trailing slash needed, just the address itself.
Two things worth setting before you hit Run Test:
Region
We test from five locations: Cape Town, Frankfurt, Singapore, St Louis, and Sydney. This matters more than people expect. A server that pings beautifully from Frankfurt can look completely different from Cape Town or Sydney, and if a meaningful chunk of your traffic comes from a particular part of the world, that’s the region you actually want to be testing from, not wherever you happen to be sitting.
IP version
IPv4 or IPv6. Most sites are still IPv4 only, so leave it on IPv4 unless you specifically know the target has AAAA records and you want to confirm IPv6 is behaving the same way as IPv4. If it isn’t, that’s worth knowing on its own.
Hit Run Test and we send ten packets and time each one as it comes back.
Understanding the ping results
The results break down into a few blocks:
Average RTT
Round-trip time, the average time in milliseconds for a packet to reach the target and come back. Lower is better. Under 50ms is generally excellent, under 150ms is fine for most purposes, and anything creeping toward 300ms or beyond on a regional test is worth a closer look.
Round-trip time (min to max) and standard deviation
The average alone can hide a lot. A min/max range of 18ms to 22ms with a tight standard deviation tells you the connection is stable. A min/max of 18ms to 210ms tells you something very different, even if the average looks fine, because it means the path is inconsistent, which usually points to congestion, a flaky hop somewhere along the route, or a routing issue that only shows up intermittently.
Individual packet details
This is the table showing sequence number, TTL, and time for each of the ten packets individually. This is usually the most useful part of the whole test, because averages smooth things over. If packet 3 spikes to 180ms while the others sit around 20ms, that one packet is telling you something the average will never show you.
Geolocation and network (ASN)
This tells you where the resolved IP is actually located and which network it belongs to. It’s a fast way to sanity check that DNS is pointing where you think it is, particularly useful right after a migration or a CDN switch, when a stale DNS record can sit there working “well enough” for weeks before anyone notices something’s off.
Packet loss
The percentage of the ten packets that never came back at all. Anything above 0% on a short test like this is worth paying attention to. Occasional single-digit loss can happen on a congested path and not mean much, but consistent loss across repeated tests usually means a real problem somewhere between the test point and the target.
What a ten-packet loss test can and can’t tell you
Ten packets means packet loss can only ever land on 0%, 10%, 20%, 30%, and so on up to 100%. There’s no way to see 2% loss or 7% loss in a ten-packet sample, the math simply doesn’t allow it. A result of 0.0% means none of those ten happened to drop, not that the path is loss-free. If the real underlying loss rate on a link is something like 3-5%, a ten-packet test will show 0% more often than not, and can still miss the problem entirely.
That’s not a flaw specific to this tool, it’s true of any short ping test regardless of who runs it. Ten packets is enough to catch a badly broken path, high loss shows up fast, but it’s still the wrong sample size for confirming a path is genuinely clean. For that you need a lot more packets than ten, which is exactly what a tool like mtr is built for, sending continuous pings to every hop along the route and reporting loss as a real percentage over hundreds of samples instead of a coarse ten-packet guess. There’s a full walkthrough with real output in the Hop Test guide, including a live example of a hop showing 0% loss while its timing spread told a very different story.
If loss is intermittent rather than constant, a chunk drops every few minutes rather than steadily, a single test run at any sample size will still only catch it if you happen to run it at the wrong moment. That’s the case for repeated testing over time rather than one-off checks, which is the gap Enterramon Pro’s scheduled monitoring is built to close, running the test automatically on a schedule so an intermittent problem shows up in the history rather than depending on catching it live.
How ping can help you
Ping’s real value is as a fast way to answer one specific question: is this a network problem, or is it something further up the stack?
If ping comes back fast and clean and your site still feels slow, the connection almost certainly isn’t the bottleneck. That points you toward server processing time, database queries, or page weight instead, somewhere in the application, not the network path. If ping is slow or showing packet loss, you’ve got a legitimate network issue to chase down before you go looking anywhere else.
Running it from multiple regions can also surface CDN misconfigurations that a single test from one location would never catch. We’ve seen “global” CDNs that are quietly fast in one region and unremarkable everywhere else. And because the results include the resolved IP’s ASN and country, it doubles as a quick DNS sanity check whenever you’re not sure a change has actually propagated.
What ping is not
Ping tells you about the network path. It doesn’t tell you anything about what happens once a request actually reaches the server.
A clean ping result doesn’t mean your site loads fast. It means the network connection to the server is healthy. Page load time depends on server response time, page weight, how many resources need to load, and how the browser renders all of it, none of which ping touches at all. If you want that picture, our Server Check tool looks at server reachability, SSL, and CDN behaviour, which is a closer match to “why does my site feel slow.”
Ping also won’t show you where along the path a problem is happening, only that there is one. If you’re seeing high latency or loss and need to know which hop is responsible, that’s a job for Hop Test instead, which maps the full path hop by hop.
And a single ping test is a snapshot, not a trend. One bad result could be a momentary blip on a congested link. If you’re chasing an intermittent issue, run it a few times, ideally from more than one region, before drawing a conclusion from it.
