📡 Ping & Traceroute
Test network connectivity and trace packet routes in real-time
Test network connectivity and trace packet routes in real-time
Quickly determine if a server is reachable. "Can you ping the server?" is the first question in any network troubleshooting session. Check if your website is down, if a remote server is accessible, or if there's a network issue.
Monitor response times to remote servers. Identify high latency issues affecting VoIP quality, video conferencing, or application performance. See min, max, and average round-trip times instantly.
Trace the route packets take to reach their destination. Identify where delays or packet loss occur along the path. Essential for diagnosing routing issues or ISP problems.
Test if DNS is resolving correctly by pinging a hostname. If ping fails on the hostname but works on the IP, you know it's a DNS issue. Toggle DNS lookups to diagnose faster.
Identify intermittent connectivity issues causing dropped connections. If you're experiencing random disconnects, packet loss is often the culprit. Our statistics show exactly how many packets were lost.
Check how fast your CDN edge nodes respond from different locations. Compare latency to cdn.example.com vs your origin server to verify CDN is working correctly and improving performance.
Ping sends ICMP (Internet Control Message Protocol) echo request packets to a target host and measures how long it takes to receive echo replies. It's like a sonar ping for networks - you send out a signal and measure how long it takes to bounce back. This tells you if the host is reachable and how fast the connection is.
Traceroute shows the path (route) that packets take to reach a destination, listing each network hop along the way. Use it when ping shows high latency or packet loss - traceroute helps you identify exactly where in the network path the problem occurs. It's invaluable for diagnosing routing issues or slow network segments.
A timeout means the target host didn't respond within the expected time window (usually 2 seconds). This could mean: 1) the host is down/unreachable, 2) a firewall is blocking ICMP packets, 3) the network path is broken, or 4) the server is configured to not respond to ping requests for security reasons.
Excellent: < 20ms (local network or nearby servers), Good: 20-50ms (regional servers), Fair: 50-100ms (cross-country or international), Poor: 100-200ms (distant servers, may affect real-time apps), Bad: > 200ms (satellite, very distant, or congested networks). For gaming and VoIP, aim for under 50ms.
Packet loss occurs when data packets fail to reach their destination. Even 1-2% packet loss can cause noticeable issues: choppy VoIP calls, video stuttering, slow downloads, and game lag. 0% packet loss is ideal. If you see any packet loss, investigate your network equipment, ISP connection, or check for WiFi interference.
Ping tests network connectivity at Layer 3 (IP), but websites run on Layer 7 (application). If ping works but the website is down, the issue is likely: 1) the web server software crashed (Apache/Nginx down), 2) the application is broken (PHP/database error), 3) wrong port or firewall rules, or 4) DNS pointing to the right IP but wrong server. Ping only confirms the server is reachable, not that services are running.
TTL is a counter that decreases by 1 at each network hop. It prevents packets from looping forever in case of routing issues. Common starting TTL values: 64 (Linux/Mac), 128 (Windows), 255 (network equipment). If you see TTL=54, the packet passed through about 10 hops (64-54=10). Low TTL values might indicate the packet traveled through many routers.
Enable DNS lookups (default) if you want to see hostnames for each hop - makes results easier to read and identify. Disable DNS lookups if: 1) you want faster results (no DNS resolution delay), 2) DNS is slow or failing, or 3) you only care about IP addresses. For pure performance testing, disable it.
Many servers block ICMP ping requests as a security measure to prevent network mapping and DDoS attacks. This doesn't mean the server is down. Examples: Most Microsoft Azure VMs, some AWS EC2 instances, and security-hardened servers block ping by default. Try accessing the service directly (HTTP, SSH, etc.) to verify it's running.
Some hosting providers (including GoDaddy shared hosting) disable traceroute for security reasons. Ping will still work! If you need traceroute, consider: 1) using a VPS/dedicated server where you have root access, 2) running traceroute from your local machine, or 3) using third-party services like looking glass servers.
Server-Side Execution: This tool runs ping and traceroute commands directly from our server, not from your browser. This means you're testing connectivity from our server's location to your target, which can be useful for testing if a service is globally accessible.
Sends 4 echo request packets and measures response time for each
Calculates min, max, average latency and packet loss percentage
Maps each router hop between source and destination (up to 30 hops)
Optionally resolves IP addresses to hostnames for easier identification
A server might be unreachable from one location but accessible from another. Use online ping tools from different geographic locations to verify if it's a regional issue or global outage.
If ping fails, try pinging 8.8.8.8 (Google DNS) or 1.1.1.1 (Cloudflare DNS) to verify your internet connection is working. This helps isolate whether the issue is your connection or the target server.
Network issues can be intermittent. Run ping tests every few minutes over 30-60 minutes to catch sporadic packet loss or latency spikes that might not show up in a single test.
If ping fails on example.com, try pinging its IP address directly. If the IP works but hostname fails, you have a DNS issue. If both fail, it's a connectivity or firewall issue.
When ping shows high latency, run traceroute to identify which hop in the path is slow. If hop 5 shows 200ms but hop 4 shows 20ms, you know the problem is between those two routers.
Screenshot your ping/traceroute results when troubleshooting with ISPs or hosting providers. They'll need this data to investigate. Note the time, date, and exact error messages you're seeing.