Your WordPress site is down: a diagnostic checklist in priority order

First, confirm it is actually down

Before doing anything else, check the site from a network you are not on. A third-party checker, mobile data instead of office wifi, or simply asking someone elsewhere will tell you whether the problem is global or local. A surprising proportion of reported outages are DNS caching, a local network issue, or an overzealous security plugin having blocked the reporter's IP address.

If the site is up for everyone except one person, check whether their IP has been rate-limited or blocked. Firewall plugins do this silently and routinely, and the person affected is often the client who logs in irregularly and mistypes a password.

The checklist, outside in

1. DNS resolution

If the domain does not resolve, nothing else matters. Domain expiry is the classic version of this and it is more common than it should be, because renewal notices go to whichever address registered the domain, often years ago. Nameserver changes made during a migration and not fully propagated are the second version.

2. SSL certificate expiry

An expired certificate produces a browser warning that most visitors will not click through, which is functionally an outage even though the server is running perfectly. Automated certificates renew silently until the renewal process itself breaks, and nobody notices until the certificate lapses. Monitoring certificate expiry dates across a portfolio takes minutes to set up and prevents an entirely avoidable class of incident.

3. Host or server outage

Check your host's status page and, if you have one, their incident feed. If the server is down, your job shifts from fixing to communicating: tell the client before they tell you, give them an honest estimate, and follow up when it resolves. Being first with the news is most of the value an agency provides during someone else's outage.

4. Error establishing a database connection

This specific message means WordPress reached the server but could not reach MySQL. The usual causes are the database server being down or restarting, credentials in wp-config.php that no longer match after a migration, or the database having hit a connection limit under load. Corrupted tables are less common but do occur, and WordPress has a built-in repair mode that can be enabled in wp-config.php.

5. Resource limits and traffic

Shared hosting enforces limits on CPU, memory, processes and database connections. A traffic spike, an aggressive crawler, or an inefficient plugin running expensive queries can exhaust those limits and produce 503 errors or timeouts. Check whether the traffic is real: bot traffic and scraper activity account for a great deal of what looks like a sudden surge in popularity.

6. Recent changes

If the first five come back clean, something changed. A plugin or theme update, a core update, a PHP version bump on the host side, a caching or CDN configuration change, or an edit somebody made and did not mention. This is where an activity log earns its keep, because it turns the question from what changed into a timestamped list.

The 503, 500 and 502 distinction

• 500 Internal Server Error: something in PHP or the server configuration failed. Check error logs first
• 502 Bad Gateway: the web server could not get a valid response from PHP. Often PHP-FPM has crashed or is overloaded
• 503 Service Unavailable: the server is deliberately refusing, usually due to resource limits or maintenance mode
• 504 Gateway Timeout: something took too long. Usually a slow query or an external API call with no timeout

These distinctions matter because they point at different layers. A 502 sends you to the PHP process manager and the host; a 500 sends you to the application and its error log.

What to do while it is down

1. Tell the client before they discover it, with an honest assessment of what you know so far
2. Establish whether data is at risk, which is a different question from whether the site is reachable
3. If a recent change is the likely cause, roll it back rather than debugging forward
4. If the host is at fault, escalate and keep a record of the timestamps for your SLA reporting
5. Once resolved, write down what happened while it is fresh, because you will see this failure again

Monitoring that actually catches this

Uptime monitoring that checks only for an HTTP 200 response misses several of the failures above. A white screen returns 200. A site serving a cached page while the database is down can return 200. An expired certificate may return 200 to a checker that ignores certificate validation.

• Check for expected content on the page, not just a status code
• Validate the SSL certificate and alert well before expiry
• Monitor from more than one location so a regional network problem is distinguishable from an outage
• Track response time trends, because slow usually precedes down
• Tie downtime records to the client's SLA terms so breaches are visible rather than reconstructed later