How to Check if a Website Is Down (for Everyone or Just You)
A website does not open. Is it down for everyone, or is the problem on your side — your Wi-Fi, your DNS, your browser? And if it is your own site, where do you start? This guide walks through the checks in the order that saves the most time, from "is it just me" to the server itself.
Step 1: is it down for everyone or just you?
The fastest way to answer that is to look at the site from somewhere else:
- Open it on your phone with Wi-Fi switched off (mobile data uses a different network and usually different DNS).
- Try another browser or a private window — extensions and cached data can break pages.
- Run the website status checker. It requests the page from our server, which is a different network and location from yours, and shows the HTTP status, response time, SSL and redirects.
If the site works from our server and from mobile data but not from your home network, the problem is local: router, DNS cache, VPN, antivirus or corporate firewall. Restart the router, flush the DNS cache, disable the VPN and try again. If the site fails everywhere, read on.
Step 2: read the error
The error message already narrows down the cause:
- "This site can’t be reached" / DNS_PROBE_FINISHED_NXDOMAIN — the domain name does not resolve to an address. Go to the DNS step.
- Connection timed out / refused — DNS works, but the server does not answer: it is down, overloaded or a firewall drops the connection.
- Certificate warning (NET::ERR_CERT_DATE_INVALID and similar) — the server answers, but the SSL certificate is expired, invalid or for another name.
- A page with an error code (500, 502, 503, 404…) — the server is reachable and answering; the problem is in the application, the configuration or the URL.
The whole site or just one page?
Before digging into servers, check the scope. Open the homepage and two or three other pages, including a static one such as an image or robots.txt. If static files load but pages do not, the web server is alive and the application (CMS, database, PHP) is failing. If only one section is broken, look at what is special about it: a plugin, an external API, a heavy database query. If the homepage works but a specific link returns 404, the page may have been moved without a redirect. And if everything fails only in the admin area, the cause is often a session, cookie or security rule rather than an outage.
Step 3: HTTP status codes — 5xx vs 4xx
When a server answers, it returns a status code. The HTTP status checker shows the exact code for any URL, including every redirect along the way.
| Code | What it usually means | Typical cause |
|---|---|---|
| 500 | Internal server error | Bug in the code, failed plugin or update, wrong file permissions |
| 502 | Bad gateway | The web server or CDN cannot get a valid answer from the application behind it (PHP-FPM, Node, upstream) |
| 503 | Service unavailable | Overload, maintenance mode, process limit reached |
| 504 | Gateway timeout | The application answers too slowly; heavy queries, stuck processes |
| 403 | Forbidden | Permissions, IP blocking, a WAF or security plugin rule |
| 404 | Not found | Wrong URL, deleted page, broken rewrite rules — the server itself is up |
| 429 | Too many requests | Rate limiting by the server or CDN |
The rule of thumb: 5xx means the server side has a problem; 4xx means the server works but refuses or cannot find this particular request. A homepage returning 404 is not "down" in the usual sense — something is wrong with the URL or the routing.
Step 4: DNS problems
If the domain does not resolve, check its records with DNS lookup: does the A (or AAAA) record exist and point to the right server? Are the NS records the ones your DNS provider gave you?
Common causes:
- The domain expired. Registrars often switch the DNS to a parking page or drop it entirely. Check the expiry date in WHOIS.
- Records were changed recently. After moving hosting or DNS providers, some resolvers still return the old address until the cached TTL runs out. The DNS propagation checker compares answers from many public resolvers with the authoritative servers and shows who already sees the new value.
- Nameservers were changed at the registrar but the zone at the new provider is empty or incomplete.
For a walkthrough of every record type, see checking domain DNS records.
Step 5: an expired SSL certificate
Browsers block a site with an expired certificate behind a full-page warning, which visitors read as "the site is down". Automatic renewal usually prevents this, but it silently fails when DNS changes, a CDN is added or the renewal job stops running. The SSL checker shows the expiry date, the chain and the names covered. Details: SSL certificate check.
Step 6: hosting, CDN and third-party outages
Sometimes the problem is not your site at all. Large hosting providers, cloud platforms and CDNs publish status pages (usually status.provider.com) with ongoing incidents. If you use a CDN such as Cloudflare, its own error pages tell you which side failed: an error that names your origin server means the CDN works but cannot reach your hosting.
Also check slow, not just dead: the response time tool breaks a request into DNS, connection, TLS and time to first byte. A TTFB of many seconds points to an overloaded server or slow application, which often precedes 502 and 504 errors.
Step 7: firewalls and WAF blocking
A site can be "down" only for some visitors. Web application firewalls, security plugins, hosting-level DDoS protection and country blocks may block an IP address, a whole provider or a country. Signs: 403 or a challenge page for some people, normal access for others; the site works via mobile data but not from the office. If your own server IP or mail server is on a public blocklist, see why is my IP blacklisted.
For site owners: what to do now and next time
- Confirm the outage from outside (status checker, mobile data).
- Check the obvious: domain and certificate expiry, hosting account suspended for an unpaid invoice, disk full.
- Look at logs: web server error log and application log right at the time of failure. Most 500 errors are explained there.
- Undo the last change: a plugin update, a deploy, a configuration edit. Roll back first, investigate second.
- Restart services (web server, PHP-FPM, database) if they are stuck — and find out why afterwards.
- Contact the host with specifics: time, URL, status code, error text.
To find out before your visitors do, set up uptime monitoring that checks the site every few minutes from outside and alerts you by email or messenger. Add separate alerts for certificate and domain expiry — they are the most avoidable outages of all.