It always happens at the worst moment. You are about to send a client the link, or a campaign has just gone live, and your website will not load. The browser spins, then shows a timeout. Your heart rate goes up. Is the server down? Has something been hacked? Are customers seeing this right now?
Before you start restarting things or emailing your host in capital letters, there is one question that changes everything: is the site down for everyone, or just for you? The answer tells you where the problem is, and it takes about thirty seconds to find out.
Why "down for me" and "down for everyone" are different problems
When a website does not load, the problem can be in one of many places between your screen and the server:
- Your device: a browser extension, a stale cache, a VPN, or a security app.
- Your network: home Wi-Fi, an office firewall, or your internet provider.
- DNS: the name may resolve to an old or wrong address for you but not for others.
- The route: a network problem between your country and the server.
- The server itself: crashed, overloaded, out of disk space or out of memory.
- The hosting account: suspended, expired, or blocking certain visitors.
If the site is down for everyone, the problem is almost certainly the server, the hosting or the domain. If it is down only for you, the server is fine and the problem is somewhere on your side of the connection. Those two answers lead to completely different fixes.
The 30-second check
The Ping & Uptime Checker tests your site from more than 30 locations around the world at the same time. Choose the HTTP check, enter your address, and watch the results arrive from each country.
- Every location returns 200 OK: the site is up. The problem is on your side.
- Every location fails or times out: the site is really down. Contact your host.
- Some locations work and others fail: a regional problem, such as a network route, a CDN issue or a firewall that blocks some countries.
That single result saves you from the two most common mistakes: panicking about an outage that only affects you, and troubleshooting your own Wi-Fi while the server is actually on fire.
Understanding the four checks
The tool offers four different tests, and each answers a slightly different question.
| Check | What it does | Use it when |
|---|---|---|
| Ping | Sends small ICMP packets and times the replies | You want latency and packet loss |
| HTTP | Requests the web page and reads the status code | You want to know if the website works |
| TCP port | Opens a connection to a specific port | You want to test a service like SSH (22) or HTTPS (443) |
| DNS | Resolves the name from every location | You recently changed DNS records |
A common surprise: ping can fail while the website works perfectly. Many servers and firewalls block ping on purpose. If HTTP succeeds everywhere, the site is up, whatever ping says.
Reading ping: latency, jitter and packet loss
When ping does work, it gives you useful numbers:
- Latency is the round-trip time in milliseconds. Under 50 ms is excellent, 50 to 100 ms is good, and over 150 ms is noticeable in video calls and games. Distance is the biggest factor: a server in Frankfurt will always feel slower from Sydney than from Paris.
- Packet loss is the share of packets that never came back. Even a few percent makes calls stutter and pages load unevenly. Loss is usually more important than raw speed.
- Consistency matters too. If one location shows 40 ms on some pings and 400 ms on others, there is congestion somewhere on that route.
If the site is up for everyone except you
Work through these in order; most problems are solved by the first three.
- Try another device or network. Open the site on your phone using mobile data, not Wi-Fi. If it works, the problem is your network or computer.
- Clear the browser cache or try a private window. Old cached redirects or cookies cause surprising failures.
- Turn off your VPN and browser extensions temporarily. Ad blockers and privacy extensions sometimes block scripts or entire domains.
- Check DNS. If you recently changed hosting, your device may still use the old address. Compare the A record from the DNS Lookup with what your computer resolves. Our guide to DNS records explained covers why changes take time to spread.
- Consider an IP block. Some hosts' firewalls block IP addresses that trigger security rules, for example after several failed logins. If the site works on mobile data but never on your office or home connection, ask your host whether your IP has been blocked.
If the site is down for everyone
Now the problem is real, but it is still worth being methodical:
- Check the domain first. An expired domain takes the site and email offline. Look up the expiry date with the WHOIS Lookup.
- Check DNS. Make sure the A record points to your server's current IP address.
- Check the port. Use the TCP check on port 443. If the port is closed everywhere, the web server itself is not running or a firewall is blocking it.
- Check the response code. A 500 or 503 means the server is reachable but the application is failing, often a plugin update, a database problem or exhausted resources.
- Check your hosting dashboard for suspended accounts, exceeded limits or maintenance notices, then contact support with the evidence you have gathered. "HTTP 503 from 28 of 30 locations since 14:10" gets a much faster answer than "my site is down".
When the site is up but painfully slow
Sometimes every location returns 200 OK, but slowly. That points to the server taking too long to build each page. Run the Website Speed Tester to see the server response time, and read our guide to reducing server response time for the caching and hosting fixes that make the biggest difference.
Using it for more than emergencies
The same checks are useful on calm days too:
- Choosing a hosting region. Compare latency from the countries where your visitors live.
- Checking a CDN. Fast responses on one continent and slow ones on another suggest the CDN is not caching there.
- Confirming a firewall rule. Test a port from outside your network to make sure it is open, or closed, as intended.
- Watching DNS changes spread after a migration, location by location.
- Checking after risky changes. After a plugin update, a server restart or a new firewall rule, a quick HTTP check from around the world confirms nothing broke for visitors in other countries.
Stay calm, check first
The next time your site will not load, resist the urge to restart everything. Open the Ping & Uptime Checker, run an HTTP check, and let the world tell you whether the problem is yours or the server's. Half the time you will discover the site is perfectly fine, and the other half you will know exactly what to tell your host.
