“The site is down” can mean a dozen different things: a typo in DNS, a certificate that expired at midnight, a crashed database, a firewall blocking your office IP, or simply a stale cache on your laptop. Diagnosing it in the right order saves hours. Start with the broadest question, is it down for everyone?, and narrow down from there.
Step 1: everyone, or just you?
Enter the address into our website status checker. It requests the page from an external server and reports the HTTP status and response time.
- Down from the checker too: the problem is on the website’s side (DNS, server, certificate, hosting). Go to step 2.
- Up from the checker, down for you: the problem is between you and the site. Jump to “When it’s just you” below.
Also check the obvious: try a second device on mobile data, and look at the provider’s status page or social accounts if it’s a big service.
Step 2: does the domain resolve? (DNS)
If the browser says “This site can’t be reached” or DNS_PROBE_FINISHED_NXDOMAIN, look up the domain with the DNS lookup tool:
- No A/AAAA record: someone deleted or changed it, or the nameservers changed during a migration.
- Unexpected IP address: the domain points to an old server.
- No answer at all: the domain may have expired, or the nameservers listed at the registrar don’t host the zone. Check the expiry date with a WHOIS lookup.
Recent DNS changes take time to spread depending on the TTL; see our DNS records guide for how propagation actually works.
Step 3: is the certificate valid? (SSL/TLS)
Errors such as NET::ERR_CERT_DATE_INVALID or “Your connection is not private” mean the site is reachable but the browser doesn’t trust the certificate. Run the domain through the SSL checker to see:
- Expiry date: automated renewals fail more often than you’d think, and certificate lifetimes are getting shorter (public certificates are limited to 200 days since March 2026).
- Name mismatch: the certificate covers
example.combut notwww.example.com. - Incomplete chain: a missing intermediate certificate breaks some browsers and most API clients.
Step 4: what is the server saying? (HTTP status)
If DNS and SSL are fine, read the HTTP response. The HTTP header checker shows the status code and headers returned.
| Code | Meaning | Usual cause |
|---|---|---|
| 200 | OK | Site works; problem may be in content, JavaScript or cache |
| 301 / 302 | Redirect | Check where it goes; loops cause “too many redirects” |
| 403 | Forbidden | File permissions, security plugin or firewall/WAF block |
| 404 | Not found | Wrong URL, deleted page, broken rewrite rules |
| 429 | Too many requests | Rate limiting or bot protection |
| 500 | Internal server error | Application crash, bad .htaccess, PHP fatal error |
| 502 | Bad gateway | Proxy or CDN can’t get a valid response from the app server |
| 503 | Service unavailable | Maintenance mode, overload, process limits |
| 504 | Gateway timeout | Backend too slow: heavy queries, stuck processes |
Behind Cloudflare you may see its own codes: 521 (origin refused connection), 522 (origin timed out), 525/526 (SSL handshake or certificate problem between Cloudflare and your server). These point at your hosting, not at Cloudflare.
If you own the site
- Check the hosting control panel for resource limits, disk space and service status.
- Read the server error log; on WordPress, temporarily enable
WP_DEBUG_LOG. - Undo the last change: a plugin update, a theme edit, a new redirect rule.
- If the site is under heavy bot traffic, enable your host’s or CDN’s bot protection.
When it’s just you
If the site loads elsewhere but not for you, work through these in order:
- Hard refresh (Ctrl+F5 or Cmd+Shift+R), then try a private window to rule out cache and extensions.
- Flush your DNS cache: Windows
ipconfig /flushdns; macOSsudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. - Disable VPN, proxy or ad blocker temporarily.
- Switch networks: phone hotspot vs home Wi-Fi. If mobile works, restart your router or try a public DNS resolver (1.1.1.1 or 8.8.8.8).
- Check whether you’re blocked: too many failed logins or a strict firewall can ban your IP for a while. Site owners can check their security plugin or WAF logs.
- Check the clock: a wrong system date makes every certificate look invalid.
Some sites are also restricted by country, by your ISP, or by corporate network filters, which explains “works at home, not at work”.
Partial outages
Sometimes a site is “up” but broken in ways a simple check won’t catch:
- Homepage works, inner pages 404: usually broken permalinks or rewrite rules after a migration or update.
- Pages load without styling: CSS or JavaScript served from a CDN or subdomain that’s failing, or blocked by mixed content.
- Login or checkout fails: sessions, the payment gateway or a third-party API is down.
- Works in one country only: geo-blocking, a CDN region problem or DNS records that differ by location.
- Email down but website up: MX or email-authentication records changed, often during a hosting move.
Test the specific URL and feature that’s failing, not just the homepage.
What to do next
- Visitors: wait and retry, follow the service’s status page, or contact support with the exact error message and time.
- Owners: contact your host with the status code, the time it started and what changed. Set up uptime monitoring so you hear about outages before your customers do.
Quick diagnosis checklist
- External status check: down for everyone, or only you?
- DNS: does the domain resolve to the right IP, and is the domain registration active?
- SSL: is the certificate valid, unexpired and covering the exact hostname?
- HTTP: which status code comes back, and does it redirect correctly?
- Local: cache, DNS cache, VPN, network, firewall and system clock.