---
title: "What A Real WordPress Uptime Problem Looks Like From The Logs"
url: https://hostmy.blog/wordpress-downtime/
date: 2026-09-12
modified: 2026-09-03
lang: en
author: "Aditya Sharma"
description: "A WordPress site going down has about six distinct causes, and each leaves a different signature in the logs. Here is how to tell them apart."
categories:
  - "Hosting"
image: https://hostmy.blog/wp-content/uploads/2026/09/hmb-card-1859-1024x538.jpg
word_count: 1566
---

# What A Real WordPress Uptime Problem Looks Like From The Logs

"The site is down" is a symptom, and it has roughly six causes. Each one leaves a different fingerprint across the logs, and telling them apart takes about ten minutes if you know the order to look.

Guessing instead is what turns a short outage into a long one. Restarting things until the site comes back does work, sometimes, and it leaves you with no idea what happened, which guarantees a second occurrence.

Here is the reading order, the signature of each cause, and the commands that produce the evidence.

## First, get the exact time window

Everything downstream depends on this. From your monitor, note the first failed check and the first recovered check, to the minute, and note the timezone your server logs use. Server logs are frequently in UTC while your monitor reports in local time, and an hour of confusion here is the most common self-inflicted wound in incident work.

Then answer three questions before opening anything:

- Was it every URL, or one URL? A single broken page is a code problem. Every page is infrastructure.

- Was it every visitor, or only logged-in users? Logged-in only usually means the page cache was serving fine and PHP was not.

- Did requests reach your server at all? This is the one that splits the problem in half.

## The single most useful diagnostic is an empty access log

If the access log has no entries during the outage window, the failure happened before your server. DNS, the CDN, the network, or the host's edge. Nothing inside WordPress can cause an absence of requests.

If the access log is full of entries returning 500, 502 or 504, the request reached you and something inside the stack failed. Different investigation entirely.

`# Count status codes across the whole log
awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn

# Narrow to the outage minute, adjust the pattern to your log format
grep "02/Sep/2026:14:2" /var/log/nginx/access.log | awk '{print $9}' | sort | uniq -c | sort -rn`

Log paths vary by stack. Common ones: `/var/log/nginx/`, `/var/log/apache2/`, a per-site directory under your panel, `wp-content/debug.log` for WordPress-level errors, and a PHP-FPM log named for the PHP version.

## The six signatures

| Cause | Status codes | Where the proof is | Shape over time |
| ----- | ------------ | ------------------ | --------------- |
| PHP fatal error | 500 | `PHP Fatal error` in the error log | Starts abruptly, often right after a change |
| PHP-FPM workers exhausted | 502, 504 | `max_children` warning in the FPM log | Builds, then a cliff |
| Database unavailable | 500, or the WordPress database message | MySQL error log, `Too many connections` | Abrupt, often with a restart |
| Out of memory kill | Mixed, often 502 | `dmesg` showing a killed process | Abrupt, process disappears |
| Disk full | 500, failed writes | `No space left on device` | Gradual, then everything fails at once |
| Upstream, DNS or network | Nothing reaches you | Empty access log for the window | Clean start and clean end |

### PHP fatal error

The clearest one to diagnose. Find it directly:

`tail -n 300 /var/log/nginx/error.log | grep -i "PHP Fatal"
grep -i "PHP Fatal" wp-content/debug.log | tail -n 20`

Then correlate with what changed. File modification times are the fastest way to see recent activity:

`ls -lt wp-content/plugins/ | head -10
ls -lt wp-content/themes/ | head -10`

If a plugin directory was modified two minutes before the first 500, you have your answer. The fix is a rollback, and the prevention is a staging test plus a post-update page check, which is the argument in [the three ways staging quietly diverges](/wordpress-staging/).

### PHP-FPM worker exhaustion

The 502 and 504 case, and the one most often misdiagnosed as a traffic problem.

`grep -i "max_children" /var/log/php*-fpm.log | tail -n 20`

The mechanism matters here. Each PHP-FPM worker handles one request at a time. If requests take longer than usual, workers stay occupied, the pool fills, and new requests queue and then time out. The trigger is often not traffic volume at all. A slow external API called on page load, a slow database query, or an uncached route hit by a crawler will occupy workers just as effectively as real visitors.

So the question to ask is not "did traffic spike" but "did requests get slower". Look at the response time column if your log format records it, and look at what the slow requests have in common.

### Database unavailable

The distinctive WordPress error message points here, but the cause splits three ways: the database server ran out of connections, the database server was killed, or the credentials or host changed.

`wp db query "SHOW GLOBAL STATUS LIKE 'Max_used_connections';"
wp db query "SHOW GLOBAL VARIABLES LIKE 'max_connections';"`

If the first number reached the second during the window, connection exhaustion is your cause, and it is usually downstream of slow queries holding connections open. Table growth and slow queries are related, which is one reason the review in [what grows in the database, and what to prune](/wordpress-database-maintenance/) is worth doing before it becomes an incident.

### Out of memory

On a small server, the kernel's OOM killer terminates whatever process is using the most memory, which is frequently MySQL. The site then fails with a database error that has nothing to do with the database being misconfigured.

`dmesg -T | grep -i "out of memory"
grep -i "oom" /var/log/syslog | tail -n 20`

Seeing `Killed process... mysqld` there is definitive. The cause is undersizing, which is often [what an oversold budget plan costs you](/cheap-shared-hosting-economics/), or a memory leak, or a spike in concurrent PHP workers each holding memory. The fix depends on which.

### Disk full

The failure that takes down several things at once and looks like several unrelated problems.

`df -h
du -sh /var/log/* 2>/dev/null | sort -h | tail -10
du -sh wp-content/uploads wp-content/cache wp-content/debug.log 2>/dev/null`

The usual culprit is not content. It is a debug log left enabled, a cache directory with no eviction, or backup archives written to the same disk they are meant to protect. That last one is worth checking today rather than during an incident, and it belongs on the recurring list in [a maintenance month, hour by hour](/wordpress-maintenance-service/).

### The one that is not you

An empty access log, a clean start and a clean end, and no correlated error anywhere. That is upstream: the host's network, the CDN, DNS, or a certificate that expired. Certificate expiry has a distinctive signature, in that browsers fail loudly while your server logs look completely normal, because the connection never completes.

## Reconstruct the timeline, not just the cause

Once you have a cause, write down the sequence. What changed in the thirty minutes before the first failure, what the first failure was, what recovered it, and whether recovery was your action or the problem passing on its own.

That last distinction matters more than it seems. A site that recovered on its own most likely hit a resource ceiling that will be hit again. A site that recovered because you rolled back a plugin has a known cause and a known fix. Treating the first case as resolved is how the same outage happens weekly.

Keep the record. Five lines is enough: time, symptom, evidence, cause, prevention. The value shows up the third time, when the pattern becomes obvious and the fix moves from restarting things to changing something structural.

## What each cause tells you to prevent

| Cause | Prevention that actually works |
| ----- | ------------------------------ |
| PHP fatal after update | Staging test plus an automatic page check after every update batch |
| Worker exhaustion | Page caching, a timeout on every external API call, fixing slow routes |
| Connection exhaustion | Slow query review, sensible pool limits, object caching |
| Out of memory | Right-size the server, or cap concurrent workers to fit the memory |
| Disk full | Log rotation, cache eviction, backups stored off the server |
| Upstream failure | Certificate expiry alerting, a second monitoring location, a known host contact |

Notice that only two of the six are fixed by anything resembling an uptime monitor. The rest are found by reading logs, which is the wider point made in [monitoring that stays credible](/wordpress-monitoring/) and in [what fails without announcing itself](/what-breaks-when-nobody-is-watching/).

## Where Host My Blog fits

All of the above is public knowledge and free tooling. The commands here work on any Linux host where you have shell access.

Worth separating from all of this: a site being reachable by a browser and a site being cheap to fetch and parse for an AI crawler are different properties, and the second one is settled inside WordPress rather than in the server logs. RankReady is a WordPress AI SEO plugin that handles that side, with post level schema, a Markdown copy of each page, robots.txt rules for AI crawlers, and an llms.txt file if you want one. Setup takes about five minutes, and it runs alongside Rank Math, Yoast, AIOSEO or SEOPress rather than replacing them, so titles, meta descriptions and the sitemap stay with whichever plugin already owns them. The scope is crawlability and machine readability, never what an assistant decides to quote. It is on [the WordPress.org plugin directory](https://wordpress.org/plugins/rankready-ai-llm-seo/).

What Host My Blog provides is somebody who already knows the reading order at 2am, which is [the attention a managed plan is really selling](/managed-wordpress-hosting/), and a record of what happened last time so the same failure does not get diagnosed from scratch twice. If you have shell access and the patience to read a log properly, you can run this yourself, and you will understand your own site better than any provider will.

The question that decides whether you need help: the last time your site went down, do you know which of those six causes it was, and can you point at the log line that proves it?