A WordPress site is usually down for one of nine reasons: a plugin or theme update that threw a fatal error, a database connection failure, an expired SSL certificate, a PHP memory limit hit, a bad or malformed edit to a core file, a host or server outage, a DNS problem, a traffic spike that overwhelmed shared hosting, or a compromised site. The tricky part is that most of these do not return a clean error page. The server keeps answering with a 200 while the page shows a blank screen or a database message, so a basic uptime checker calls the site healthy while your visitors see it broken.
Work the list below from the top. It is ordered roughly by how often each cause shows up in practice, and each entry has the fastest way to confirm it and the fix.
First: is it down for everyone, or just you?
Before you touch anything, rule out your own connection. Open the site on your phone over cellular data, not wifi, and try an incognito window on your computer. If it loads on mobile data but not on your laptop, the problem is local: a cached page, a DNS resolver, or a browser extension. If it is down everywhere, keep reading. A quick external check from three regions also settles this in seconds, which is exactly what a monitor does for you automatically.
The 9 most common causes, and how to fix each
1. A plugin or theme update broke it (the white screen of death)
This is the number one cause. An update introduces PHP that your version cannot run,
WordPress hits a fatal error, and it serves a blank white page, often with a 200 status.
To confirm, open the site with ?debug disabled and look at the page source:
an empty <body> or a “There has been a critical error”
message points straight here.
Fix it by disabling the culprit. If you can reach wp-admin, deactivate plugins one at a
time, newest update first. If you are locked out, rename the plugin folder over SFTP
(for example wp-content/plugins/broken-plugin to
broken-plugin.off); WordPress deactivates anything it cannot find. For a
theme, switch to a default theme by renaming the active theme folder. Turn on
WP_DEBUG in wp-config.php to see the exact file and line.
2. Error establishing a database connection
WordPress stores everything in MySQL, and when it cannot reach the database it prints that exact sentence. Causes are a wrong database password after a host migration, a crashed MySQL service, or a database that ran out of connections under load. Confirm by reading the message on the page itself, and check whether wp-admin shows the same error.
Fix by verifying DB_HOST, DB_USER, DB_PASSWORD
and DB_NAME in wp-config.php against your host control panel.
If credentials are right, the database service itself is likely down, and that is a
support ticket to the host. On shared hosting, a repeated connection error under traffic
usually means you have outgrown the plan.
3. The SSL certificate expired
An expired TLS certificate hides the entire site behind a full-page browser warning that says the connection is not private. The site is technically up, but nobody will click through the scare screen. This is the most preventable outage there is, and it happens because no single person owns the renewal date across a pile of domains.
Fix by renewing the certificate. If you use Let's Encrypt, the auto-renewal cron may have failed silently; re-run it and check the renewal hook. Going forward, put an expiry warning on the domain so you hear about it 30, 14 and 7 days out instead of the morning it lapses. Automated SSL certificate monitoring does exactly that, and our walkthrough of what to do when a certificate has already expired covers the emergency path.
4. PHP memory limit exhausted
A heavy plugin, a large import or an image-processing job can blow past the PHP memory
limit, and WordPress dies mid-render with an “Allowed memory size exhausted”
fatal. You will see it in the error log and sometimes at the bottom of a half-rendered
page. Raise the limit in wp-config.php with
define('WP_MEMORY_LIMIT', '256M');, and if that only delays the crash, find
the plugin that is leaking and replace it.
5. A bad edit to a core file or wp-config
One stray character in wp-config.php, functions.php or an
.htaccess file will take the whole site down with a parse error or a 500.
This is common right after a manual code edit or a snippet pasted from a tutorial.
Restore the file from a backup, or fix the syntax over SFTP. A missing semicolon or an
extra closing PHP tag is the usual offender.
6. Your host or server is down
Sometimes it genuinely is not your fault. The host had a hardware failure, a network incident or maintenance that ran long. Check the host status page and your inbox for a maintenance notice. If the whole box is unreachable, there is nothing to fix on your end except escalate, and, longer term, consider whether the host's reliability matches what your site is worth. A repeatable, zero-downtime deployment and server workflow removes a whole class of these self-inflicted outages that happen during a deploy.
7. A DNS problem
If the domain stops resolving, the site is unreachable even though the server is fine. It happens after a nameserver change, an expired domain registration, or a DNS provider outage. Confirm with a DNS lookup: if the A record is missing or points to the wrong IP, that is your answer. Fix the record at your DNS provider, and remember propagation can take up to a few hours.
8. A traffic spike overwhelmed the server
A post takes off, or a campaign lands, and shared hosting cannot serve the load. The site starts returning 503 or timing out at the exact moment the traffic is most valuable. Confirm by correlating the outage with an analytics spike. Fix it with page caching, a CDN, and, if it keeps happening, a bigger plan. Catching it in real time is what lets you clear the cache or upgrade while the traffic is still there.
9. The site was hacked
A compromised WordPress site may redirect visitors, show spam, or get taken offline by the host for serving malware. Confirm with a malware scan and by checking for unfamiliar admin users and recently modified core files. Fix by restoring a known-clean backup, updating everything, rotating all passwords and salts, and removing the injected code. Then find the entry point, usually an outdated plugin, so it does not happen again.
alertping
Find out your WordPress site is down before your visitors do
A keyword check reads the real page, so the white screen and the database error count as down. 30-second checks, 3-region confirmation, SMS included.
Why a status-code check keeps saying your site is up
Notice how many of those causes leave the server answering normally. The white screen of death, the database error, a hacked page and a slow-but-alive server all return a 200 or load something. A monitor that only checks the HTTP status code will call every one of them healthy. That is why people find out from a customer email instead of an alert.
The fix is a content assertion. Pick a word that only appears when the page renders correctly, your site name in the header or a menu item, and have the monitor confirm it is present on every check. When a plugin update swaps the homepage for a blank page, the keyword disappears and you get paged. This one setting catches more real WordPress downtime than any status code. It is the core idea behind WordPress uptime monitoring done properly, and it needs no plugin installed on the site. If your WordPress install is running WooCommerce, WooCommerce uptime monitoring extends the same assertion to the cart and checkout pages that actually take money.
How to stop guessing next time
You cannot fix an outage you do not know about. Set up external monitoring so the next incident starts with a text message, not a customer complaint:
- Check the homepage with a keyword assertion every 30 to 60 seconds, so a white screen counts as down.
- Check the checkout or a key logged-in path separately, because those break on their own.
- Watch the SSL certificate expiry, so number three on this list never happens again.
- Confirm from more than one region, so a single network blip does not wake you for nothing.
- Route alerts to SMS and Slack, so the right person sees it at 3am.
Do that, and “why is my WordPress site down?” stops being a question you answer after the damage is done, and becomes an alert you act on while the outage is still measured in minutes.