Ping: a beginner's guide
Real ICMP ping from 18 global cloud regions
Ping: the simplest way to ask "how far away is this server?"
Ping is the oldest and simplest network diagnostic in existence. It works by sending a tiny packet from one computer to another using a special low-level protocol called ICMP (Internet Control Message Protocol), and waiting to see how long it takes the destination to send a reply back. The round-trip time, measured in milliseconds, is the latency between the two endpoints. A ping of 5 ms means the two computers are very close (network-wise); a ping of 200 ms means there is a lot of distance, congestion, or both between them. Ping was invented by Mike Muuss in 1983 and named after the sound a sonar makes when it bounces off something. The name has stuck for over forty years.
You should care because ping is the cheapest, fastest way to get a real measurement of network latency between two points. Every other network performance question — "why is my website slow for users in Sydney?" or "is the new CDN region working?" or "is there packet loss between my office and the data center?" — starts with a ping test. The information ping gives you is much smaller than what a full network test would produce, but it is also instant and free, and it is correct. A ping result of 187 ms is unambiguous in a way that almost no other network metric is.
The five things every ping check measures:
Round-trip time (RTT). The total time from sending the packet to receiving the reply.
Average RTT. Most ping tests send several packets in a row (typically 4 or 10) and report the average. This smooths out one-off spikes.
Minimum and maximum RTT. The fastest and slowest of the round-trips, which tells you how stable the connection is.
Jitter. The variation in RTT across the packets — high jitter means an inconsistent connection.
Packet loss. What percentage of the sent packets never received a reply at all? Even small packet loss is a strong negative signal.
Three questions a ping check answers:
How fast is the network path between my user and my server?
Is the connection stable, or is it dropping packets?
For a customer reporting that my site is slow, is the network actually slow for them?
The cost of skipping ping checks is debugging "slow website" complaints without any actual measurements. The fix is to run a ping test from a location near the affected user. Ping has been part of every major operating system since the 1980s — the command is just `ping example.com`. For more detailed tests across many global locations at once, public services like Globalping and the RIPE Atlas network make multi-region tests just as easy.
The Ping endpoint, in plain language
In one sentence: Real ICMP (Internet Control Message Protocol) ping from 18 global cloud regions
Performs real ICMP (Internet Control Message Protocol) ping (the official internet standard) from up to 18 geographically distributed cloud regions via the Globalping network. Probes run from AWS, GCP, or Azure datacenters and return min/avg/max/median RTT, jitter (standard deviation), packet loss percentage, and per-packet timing data. Supports filtering by cloud provider, region, geography, or probe zone.
Don't worry if some of the words above are still unfamiliar — there's a plain-language glossary at the bottom of this page, and most of the terms link to their own beginner guides if you want to learn more.
What is actually happening when you call it
Here's what's actually happening behind the scenes when you call this endpoint:
Creates ICMP (Internet Control Message Protocol) Echo Request measurements via the Globalping network, targeting probes in specific cloud provider regions (AWS, GCP, Azure). Returns actual ICMP round-trip times with comprehensive statistics: min/avg/max/median RTT, jitter (standard deviation across zones), aggregate packet loss percentage, resolved IP (Internet Protocol address) address, and probe network ASN (Autonomous System Number). Supports filtering by cloud provider regions, probe zone IDs, or geographic region.
If you're using an AI assistant through MCP, you don't need to understand any of the technical details — the assistant calls the tool and translates the result for you.
Why this specific tool matters
Let's skip the marketing fluff and answer the only question that actually matters: why should you, a real human with a real to-do list, care about the Ping tool? Here's the plain-English version, written the way you'd hear it from a friend who happens to do this for a living.
Get authentic ICMP (Internet Control Message Protocol) latency data from real cloud provider regions — not HTTP (HyperText Transfer Protocol) overhead, but true network-level round-trip times per the official internet standard (ICMP) and the official internet standard (ICMPv6). Essential for CDN (Content Delivery Network) optimization, multi-cloud performance comparison, SLA (Service Level Agreement) verification, geographic load balancing decisions, and ensuring consistent user experience across regions. Jitter and median metrics provide a more accurate picture than averages alone.
Picture this in real life. Imagine an SRE / platform engineer. Here's the situation they're walking into: Measure service latency from all major geographic regions before a global launch. Establish baseline p50/p95 latency metrics per region and set alerting thresholds. Without the right tool, that person would be stuck copy-pasting between five browser tabs, reading documentation written for engineers, and crossing their fingers that the answer they cobble together is correct. With the Ping tool, the same person gets a clear answer in seconds — no spreadsheets, no guessing, no waiting for someone on the infrastructure team to free up.
Three questions this tool answers in plain English. If any of these have ever crossed your mind, the Ping tool is built for you:
Where in the world is this server actually located, and who runs the network it sits on?
How fast does traffic move between my users and my service?
Is the IP address I am looking at part of a residential network, a data center, or something suspicious?
You can either click the tool and get the answer yourself, or ask your AI assistant — connected through MCP (Model Context Protocol) — to ask the question for you and translate the answer into something you can paste into Slack.
Who gets the most out of this. Network engineers, IT admins, sales teams qualifying enterprise prospects, and product teams building geo-personalization or fraud rules. If you see yourself in that list, this is one of the EdgeDNS tools you should bookmark today.
What happens if you skip this entirely. Skip it and you can't tell where your users actually are, who runs the network they're on, or why they're seeing slow page loads. That's why running this check — even once a month — is one of the cheapest forms of insurance you can give your domain.
Available on the pro plan. The technical details: `GET /v1/network/ping`.
When would I actually use this?
If you're still on the fence about whether the Ping tool belongs in your toolbox, this section is for you. Below you'll meet three real people — an SRE / platform engineer, a cloud architect, a devops engineer, and an NOC engineer — facing three real situations where this tool turns a stressful afternoon into a five-minute task. Read whichever story sounds closest to your week.
Story 1: Global Performance Baseline
Imagine you're an SRE / platform engineer. Measure service latency from all major geographic regions before a global launch. Establish baseline p50/p95 latency metrics per region and set alerting thresholds.
Why it matters: Identify regions with poor performance before users complain and set data-driven SLA (Service Level Agreement) targets.
Story 2: Multi-Cloud Provider Comparison
Imagine you're a cloud architect. Compare ICMP (Internet Control Message Protocol) latency from AWS, GCP, and Azure regions to your service simultaneously. Evaluate network-level performance differences between cloud providers for the same geographic region.
Why it matters: Data-driven multi-cloud architecture and provider selection decisions backed by real latency data.
Story 3: CDN & Anycast Verification
Imagine you're a devops engineer. Compare latency with and without CDN (Content Delivery Network) from various cloud provider regions. Verify anycast is routing users to the nearest edge. Detect CDN misconfigurations where certain regions hit distant origins.
Why it matters: Validate CDN (Content Delivery Network) effectiveness, identify geographic routing gaps, and optimize edge configuration.
Story 4: SLA Monitoring & Incident Response
Imagine you're an NOC engineer. During an incident, quickly measure reachability and latency from 18 global vantage points to determine if an outage is regional or global. Compare against baseline metrics.
Why it matters: Rapidly scope the geographic impact of incidents and verify SLA (Service Level Agreement) compliance with evidence.
Common situations across teams. Beyond the three stories above, here are the everyday workplace moments when people across the company reach for the Ping tool — or one of the tools right next to it in this category. If any of these are on your calendar this month, that's your sign:
When a customer reports that your site is slow specifically from their region.
When you need to know whether traffic is coming from a residential network or a data center.
When planning a CDN, points of presence, or geographic expansion.
During an outage, to see exactly where in the route packets are getting lost.
If you can see yourself in even one of those bullets, the Ping tool will pay for itself the first time you use it.
Still not sure? Here's the easiest test in the world. Open Claude, ChatGPT, Gemini, or any other AI assistant connected to the EdgeDNS MCP server and ask, in your own words: "Is the Ping tool useful for my job?" The assistant will look at the tool, ask you a couple of follow-up questions about what you're trying to accomplish, and give you a straight answer in plain English. No commitment, no signup forms, no jargon.
The easiest way: just ask your AI assistant
If you've connected the EdgeDNS MCP server to Claude, ChatGPT, Gemini, Cursor, or any other AI assistant, you don't need to write any code. Just ask in plain English:
"Use the Ping tool to check example.com and explain anything that looks wrong in plain language."
The AI will figure out which tool to call, fill in the right parameters, run it, and then explain the result back to you. No copy-pasting between tabs. No reading raw JSON. No memorizing endpoint names.
MCP (Model Context Protocol) access is free on every plan, including the free tier. One API key works for both REST and AI — you do not have to choose.
The technical way: call it from code
If you're a developer and want to call the endpoint from a script or your own application, here's the simplest possible example. Replace the placeholder API key with the real one from your dashboard.
# Replace edns_live_YOUR_KEY with your real API key from the dashboard
curl -H "Authorization: Bearer edns_live_YOUR_KEY" \
"https://api.edgedns.dev/v1/network/ping?host=example.com"What you need to provide
You need to provide 5 pieces of information when you call this tool. The table below lays them out side by side, with a real example for each one so you can see exactly what to send.
| Field | Type | Required? | What it means | Example |
|---|---|---|---|---|
host | string | Yes | Target hostname or IP (Internet Protocol address) address to ping | example.com |
provider | string | Optional | Cloud provider for region filtering: "aws", "gcp", or "azure". Defaults to "gcp". | gcp |
region | string | Optional | Cloud provider region code. When combined with provider, pings from the nearest probe zone for that region. | us-east-1 |
zones | string | Optional | Comma-separated probe zone IDs (e.g., us-east,eu-west,ap-northeast). Use /ping/locations to see available zones. | us-east,eu-west,ap-northeast |
geography | string | Optional | Filter by geography: North America, South America, Europe, Asia Pacific, Oceania, Middle East, Africa | Europe |
What you get back
When you call this tool, you'll get back a JSON object with the fields below. If you're talking to it through an AI assistant, the assistant reads these for you and explains them in plain language — you don't need to memorize them.
| Field | Type | What you'll see in it |
|---|---|---|
host | string | The target host that was pinged |
measurement_type | string | Measurement type: "ICMP" |
results | array | Per-zone ping results with ICMP (Internet Control Message Protocol) stats, resolved IP (Internet Protocol address), and probe network info |
results[].icmp_stats | object | ICMP (Internet Control Message Protocol) statistics: min, max, avg RTT (ms), packets_sent, packets_received, packet_loss |
results[].timings | array | Per-packet timing data with TTL (time to live) and RTT in milliseconds |
results[].resolved_address | string | Resolved IP (Internet Protocol address) address of the target from this probe's perspective |
results[].probe_network | string | Network name of the probe (e.g., "Amazon.com", "Google") |
results[].probe_asn | number | ASN (Autonomous System Number) of the probe network |
zones_tested | number | Number of probe zones tested |
successful | number | Number of zones with successful pings |
failed | number | Number of zones where ping failed |
avg_latency_ms | number | Mean ICMP (Internet Control Message Protocol) latency across all zones |
median_latency_ms | number | Median (p50) ICMP (Internet Control Message Protocol) latency across all zones — more robust than average |
jitter_ms | number | Jitter (standard deviation) of latency across zones — measures consistency |
packet_loss_pct | number | Aggregate packet loss percentage across all zones |
min_latency | object | Zone with lowest latency (zone, city, latency_ms) |
max_latency | object | Zone with highest latency (zone, city, latency_ms) |
available_zones | object | Available probe zones grouped by geography |
available_providers | object | Count of regions per cloud provider (aws, gcp, azure) |
Words you might be wondering about
If any words on this page felt like jargon, here's a plain-language version. Click any linked term to read a full beginner-friendly guide.
IP (Internet Protocol address) — A unique number that identifies a computer on the internet, like a phone number for a server.
CDN (Content Delivery Network) — A worldwide network of servers that store copies of your website close to your visitors so pages load fast.
HTTP (HyperText Transfer Protocol) — The language web browsers and websites use to talk to each other.
ASN (Autonomous System Number) — A unique number assigned to a big network operator (like an ISP or cloud provider). Tells you who owns a chunk of the internet.
ICMP (Internet Control Message Protocol) — The "knock-knock" of the internet. Tools like ping use it to check whether a server is reachable and how long the round trip takes.
RFC (Request for Comments) — The official internet standards documents. When someone says 'RFC 8484' they mean a specific numbered standards document — in that case, the one defining DNS over HTTPS.
SLA (Service Level Agreement) — A written promise about how reliable a service will be — for example, "99.9% uptime."
Need Programmatic Access?
Automate domain intelligence with 100+ API endpoints and a free MCP server for AI integration.