My WordPress site is down: diagnostic checklist

First rule: “is WordPress down?” almost never means wordpress.org is down. It means your WordPress site is down. The wordpress.org website and the WordPress software itself have independent infrastructure – their outages are rare and short-lived, and a search for “is WordPress down” from a working internet connection always returns “no.” What you actually need is a way to find out what part of your own stack is broken.

This guide is the top-down diagnostic: which of the six possible layers between your visitor’s browser and your WordPress database is actually failing, how to confirm it in under a minute, and which specific fix-it article to jump to once you know. Work through the layers in order – most outages get diagnosed in the first three steps.

30-second triage: is it really down?#

Before touching anything, confirm the site is actually down for everyone, not just for you. Three checks that take less than a minute:

1. Try a different network. Load the site on your phone over cellular (not Wi-Fi – different DNS resolver, different route). If it loads on cellular, the problem is your local network or ISP, not the site.
2. Use an independent uptime probe. Load https://downforeveryoneorjustme.com/ or https://isitdownrightnow.com/ and enter your domain. These check the site from a third-party data center. A green result means your site is reachable from somewhere, so the problem is on your side, not the server.
3. Check a status page or second browser profile. If you only use one browser, an aggressive ad blocker or corrupt browser cache can produce what looks like a site-wide outage. Open a private/incognito window or a completely different browser.

If any of these three loads the site fine, stop – the “outage” is local to you. If the site is unreachable from every check, it is actually down and the rest of this guide applies.

Where in the stack is it failing?#

A request from a visitor’s browser to your WordPress site passes through six distinct layers. Any one of them can fail in a way that looks like “the site is down”:

Work the layers top-to-bottom. Most WordPress “outages” resolve at step 2, 4, or 6.

Step 1: Confirm client-side is not the problem#

Already covered in the 30-second triage above. Move on if the site is down from multiple networks.

Step 2: DNS resolution#

If DNS is broken, the browser never reaches your server at all – the URL just returns “server not found.” The error in the browser varies: Chrome says DNS_PROBE_FINISHED_NXDOMAIN or DNS_PROBE_FINISHED_BAD_CONFIG , Firefox says “Hmm, we’re having trouble finding that site,” Safari says “cannot find the server.”

Check it

# Does the domain resolve at all?
dig yoursite.com

# What IP does your current DNS resolver return?
dig yoursite.com +short

# Check against a known-good public DNS
dig @8.8.8.8 yoursite.com +short
dig @1.1.1.1 yoursite.com +short

If dig returns no answer (or an empty ANSWER SECTION), DNS is broken. If it returns an IP but that IP is wrong (pointing at your old hosting provider, for example), DNS points the wrong direction.

On Windows PowerShell, substitute Resolve-DnsName yoursite.com or use nslookup yoursite.com .

Common causes and fixes

• Domain registration expired. Log into the registrar. A suspended domain often produces a “no such domain” error rather than a DNS error per se, but the symptom is identical.
• DNS records were deleted or changed. Verify the A record for the apex and any CNAME for www in your DNS provider’s dashboard.
• DNS propagation after a change. Changes to DNS can take up to 48 hours to propagate globally, though most resolvers update within an hour. If you just moved hosts, wait and re-test from an uncached resolver.
• Local DNS cache stale. If your machine cached the old IP, flush it: how to flush DNS cache on Linux, Mac, and Windows.

The full diagnostic flow for DNS-level failures is in DNS errors: common causes and how to fix them. If the browser specifically reports DNS_PROBE_FINISHED_BAD_CONFIG , the walkthrough is in DNS_PROBE_FINISHED_BAD_CONFIG: what it means and how to fix it.

Step 3: SSL/TLS handshake#

DNS works, the browser reaches your server’s IP, but the HTTPS handshake fails. The visitor sees a red “Your connection is not private” warning, or a specific error like NET::ERR_CERT_DATE_INVALID or ERR_SSL_PROTOCOL_ERROR . For most users this is indistinguishable from “down” – they hit the warning and leave.

Check it

# See the certificate and whether the handshake completes
openssl s_client -connect yoursite.com:443 -servername yoursite.com < /dev/null

# Just the dates
openssl s_client -connect yoursite.com:443 -servername yoursite.com < /dev/null 2>/dev/null \
  | openssl x509 -noout -dates

If you see Verify return code: 10 (certificate has expired) , the cert is the problem. If the connection itself fails with s_client errors, it is a protocol-level handshake issue.

Common causes and fixes

• Certificate expired – Let’s Encrypt auto-renewal failed silently. Walkthrough: NET::ERR_CERT_DATE_INVALID: what it means and how to fix it.
• Handshake error – server and browser cannot agree on TLS version or cipher. Usually happens after a server update that disabled an old protocol clients still depended on: ERR_SSL_PROTOCOL_ERROR or ERR_SSL_VERSION_OR_CIPHER_MISMATCH.
• Wrong hostname in cert – cert covers yoursite.com but visitors use www.yoursite.com or vice versa. Fix is to reissue with both: ERR_CERT_COMMON_NAME_INVALID.

Step 4: Origin server reachable#

DNS works, SSL works, but the server itself is not responding. The browser timeout produces ERR_CONNECTION_TIMED_OUT or ERR_CONNECTION_REFUSED depending on whether the connection attempt times out or gets an immediate refusal.

Check it

# Can you ping the IP? (Not all servers respond to ping, but it is a fast first check)
ping yoursite.com

# Is port 443 open?
curl -I --max-time 10 https://yoursite.com

# Trace the route - where does the packet die?
traceroute yoursite.com  # mtr is better if available

curl -I is the most useful single command here. It sends a HEAD request and shows exactly what the server returns. Three outcomes:

• Response received (200, 500, 503, whatever) – origin is up and WordPress is responding. Move to step 5 or 6 depending on what you see.
• Timeout – server is unreachable. Firewall, server down, or packet routing issue.
• Connection refused – server is up, but nothing is listening on port 443. nginx crashed or was stopped.

Common causes and fixes

• Server powered off – VPS/dedicated server crashed or was rebooted and did not come back up cleanly. Check your host’s control panel.
• nginx/Apache down – the web server process crashed. SSH in and systemctl status nginx . Restart with systemctl start nginx .
• Firewall blocking traffic – a rule change, a fail2ban escalation that banned a broader range than intended, or Cloudflare “I’m Under Attack” mode rejecting legitimate traffic.
• IP address changed – rare, but hosts sometimes renumber. Verify the DNS record still points to the current origin IP.
• Datacenter outage – your host’s entire data center is down. Check their status page at status.yourhost.com or similar.

Error-code-specific walkthroughs:

• ERR_CONNECTION_REFUSED
• ERR_CONNECTION_TIMED_OUT
• WordPress cURL error 28 if the error is surfacing inside WordPress rather than to visitors

Step 5: CDN or proxy layer#

If your site is behind Cloudflare, BunnyCDN, Fastly, or similar, the CDN can be down or misconfigured even when your origin is fine. Cloudflare specifically shows branded error pages with their logo – if you see “Cloudflare” in the error, the problem is somewhere between Cloudflare and your origin, not your WordPress site itself.

Check it

# Bypass the CDN - hit your origin IP directly
curl -I --resolve yoursite.com:443:YOUR_ORIGIN_IP https://yoursite.com

Replace YOUR_ORIGIN_IP with the actual server IP (look it up in your host’s control panel – do not use the IP that DNS currently returns, which is the CDN IP). If the origin responds with a valid page, the problem is in the CDN layer.

Alternatively, temporarily disable Cloudflare proxy (click the orange cloud to turn it gray in the DNS section) and test the site. Re-enable it once you know if the origin works.

Common causes and fixes

• Cloudflare “Error 520” through “527” – Cloudflare reached your origin but got an invalid response. Usually means your server returned something too large, too slow, or malformed. Each 52x has its own meaning in Cloudflare’s docs.
• Cloudflare “522 Connection Timed Out” – Cloudflare could not reach your origin at all. Server is down (go back to step 4) or firewall is blocking Cloudflare’s IP range.
• “Under Attack” mode too aggressive – a legitimate traffic spike trips the WAF and Cloudflare starts challenging every visitor. Temporarily turn it off in the Cloudflare dashboard.
• Origin IP exposed in DNS history – attackers bypass Cloudflare by hitting your origin directly. The fix is to rotate the origin IP, but the symptom is an origin that is being hammered independently.

If you do not use a CDN, skip step 5 entirely and go to step 6.

Step 6: WordPress application layer#

DNS, SSL, origin, and CDN all check out – the server is returning a response – but the response is an error page, a blank page, or a partial page. At this point the problem is inside WordPress itself, and the specific fix depends on what you see.

What you see → what it means

Fast checks that catch most cases

Before going into detailed debugging, run these four commands if you have SSH. They catch the majority of WordPress-level outages:

# 1. Is the disk full? A full disk breaks everything.
df -h

# 2. Is MySQL running?
systemctl status mysql  # or mariadb

# 3. Is PHP-FPM running?
systemctl status php8.3-fpm  # match your PHP version

# 4. What does the nginx error log say in the last 5 minutes?
tail -100 /var/log/nginx/error.log

Disk full accounts for a surprising percentage of “mystery outages” – MySQL cannot write to its binary log, PHP cannot write to session storage, the cache layer fills up, and the whole stack starts failing in cascading ways. Always check disk first.

A complete reference covering 50+ other WordPress errors that are less common but possible is in how to fix the most common WordPress errors – use it as a lookup table once you know the specific error message.

Could it be a hack?

If the site is down AND you are seeing content you did not add, redirects to sketchy domains, or warnings from Google Safe Browsing, the site is likely compromised rather than just broken. My WordPress site was hacked: what to do right now covers the specific recovery workflow (different from standard outage recovery – you need to preserve evidence, rotate credentials, and identify the entry point before restoring).

Common mistakes during an outage#

• Guessing instead of checking. The symptom is “site is down.” That is not enough information to fix anything. Always run the diagnostic commands in the layer you suspect before making changes.
• Restarting the whole server. Tempting, sometimes works, but loses diagnostic information. Restart the specific failed service (nginx, MySQL, PHP-FPM) only after identifying which one.
• Clearing caches before understanding the cause. Purging the CDN, flushing Redis, and clearing WordPress cache can mask the real problem – the site appears to come back briefly, then fails again once the cache repopulates.
• Touching wp-config.php in panic. An unclosed PHP tag, an errant quote, or a truncated file turns a minor issue into a total site-down. Make a copy before editing. See wp-config.php explained for the reference.
• Assuming it is WordPress when it is infrastructure. A full third of “WordPress outages” are DNS, SSL, or CDN issues that have nothing to do with PHP or the database. Work top-down from the client.
• Ignoring the host’s status page. If your host is having a datacenter-wide incident, no amount of WordPress debugging will help. Check status.yourhost.com before spending an hour on the server.
• Making changes during the outage and during the recovery simultaneously. Multiple overlapping changes make it impossible to tell which one fixed it (or caused the next problem). One change at a time, test, next change.

How Hostney helps with downtime#

On Hostney, many of the failure modes in steps 4-6 are caught before they affect your site. Each account runs in its own container, so one site’s runaway PHP process cannot exhaust the PHP-FPM pool for everyone else on the server. MySQL is monitored continuously across the fleet – if the database service drops, the infrastructure team is alerted in under 60 seconds, typically faster than a customer notices. Disk quotas are enforced per account, which prevents the “one site fills the disk and crashes MySQL for everyone” class of shared-hosting outage.

The Hostney dashboard shows each subdomain’s current status and recent response codes, which means you do not have to guess whether the problem is your site or the platform – the dashboard is the single source of truth.

For sites that already lost the diagnostic battle (compromised, database corrupted, worst-case scenarios), snapshots make rollback straightforward – restore to yesterday, confirm the site is up, then work out what to do differently when the problem is no longer actively happening.

For most Hostney-hosted outages, the practical checklist shrinks from six steps to three: is DNS pointing at us, does your browser see an SSL warning, and what does the dashboard say? The rest of the stack is monitored at the platform level.

Summary#

“Is WordPress down” is almost always “is my site down,” and the fix depends entirely on which of six layers between the browser and the WordPress application is failing. Start with the 30-second triage (is it actually down for everyone, or just you?), then work top-down: client network, DNS, SSL, origin server, CDN/proxy, WordPress application. Each layer has its own diagnostic commands and its own specific error codes – once you know which layer is broken, the fix is a concrete action in a specific article, not open-ended panic. Run df -h early if you have SSH access, because disk-full outages cascade through MySQL, PHP, and nginx in ways that look like six different problems but are really one. And check your host’s status page before assuming it is a WordPress problem – a third of WordPress “outages” are infrastructure events that no amount of plugin debugging will fix.