WordPress site down: the 15-minute emergency response checklist

#wordpress #webdev #tutorial #devops

Your client's site is down. It's 9 PM on a Friday.

What you do in the next 15 minutes determines whether this is a 30-minute fix or a 3-hour emergency. Here is the exact response process.

Step 1: Confirm the outage (2 min)

First, verify it's actually down -- not just down for you.

# Quick check from command line
curl -o /dev/null -s -w "%{http_code}" https://clientsite.com

# External check tools
# downforeveryoneorjustme.com
# isitdownrightnow.com

Also check from your phone (different network). A site "down" only for you is a local network or DNS cache issue -- very different problem.

Step 2: Identify the scope (3 min)

While the site is loading (or failing to load), answer:

Is it the entire site, or just specific pages?
Is it a white screen, a 500 error, a 503, or something else?
Is the admin dashboard accessible? (try /wp-admin)
When did it go down? (Check uptime monitor logs)
What changed recently? (Check your maintenance log)

Different symptoms point to different causes:

Symptom	Most likely cause
500 Internal Server Error	PHP fatal error, .htaccess issue
503 Service Unavailable	Server overloaded or maintenance mode
White screen (no error)	PHP memory limit, plugin conflict
"Error establishing database connection"	Database down or credentials wrong
Site loads, checkout broken	Payment gateway issue, JS conflict
Site redirects to spam domain	Malware infection

Step 3: Check server resources (2 min)

# Is the server responding at all?
ping clientserver.com

# Check disk space (full disk = 500 errors)
df -h /var/www/

# Check memory and load
free -m
uptime

# Check PHP error log
tail -50 /var/log/apache2/error.log | grep "$(date +%Y-%m-%d)"

A full disk or high load average (above 4.0 on a shared server) points to server-side issues -- contact hosting support immediately.

Step 4: Check the WordPress error log (2 min)

tail -100 /var/www/clientsite/wp-content/debug.log

No debug.log? Enable it temporarily:

// In wp-config.php
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

A PHP fatal error in the log names the exact file and line causing the crash. That is your fix target.

Step 5: The recovery actions by error type

500 / White screen -- likely plugin or .htaccess

# Rename .htaccess to test (regenerates automatically)
mv /var/www/site/.htaccess /var/www/site/.htaccess.bak

# Deactivate all plugins via database (when you can't access wp-admin)
wp --allow-root plugin deactivate --all

# Reactivate one by one to find culprit
wp --allow-root plugin activate plugin-slug

"Error establishing database connection"

# Verify database credentials in wp-config.php match actual DB
wp --allow-root db check

# Try connecting manually
mysql -u DB_USER -p -h DB_HOST DB_NAME

If credentials are correct but connection fails: contact hosting support. Database server may be down.

Malware / redirect to spam domain

# Check for recently modified PHP files (last 24h)
find /var/www/site -name "*.php" -mtime -1 -ls

# Check core file integrity
wp --allow-root core verify-checksums

# Check for injected code in index.php
head -30 /var/www/site/index.php
head -30 /var/www/site/wp-config.php

If you find modified core files: restore from backup immediately. Do not try to clean -- the infection is likely in multiple places.

Step 6: Restore from backup if needed

If you can not identify and fix the cause within 20 minutes:

# Restore database
wp --allow-root db import last_known_good_backup.sql
wp --allow-root cache flush

# Restore files (if file corruption suspected)
# Unzip backup archive over current files
unzip -o wp-content-backup.zip -d /var/www/site/

This is why backups exist. A verified, recent, off-server backup turns a potential disaster into a 5-minute restore.

Step 7: Client communication

Contact the client as soon as you confirm the outage -- before you have a fix.

Template:

"Hi [Name], I've been alerted that [site] is currently down. I'm investigating now. I'll update you within 30 minutes with either a fix or a timeline. No action needed from you."

Then update when resolved:

"The site is back up. The cause was [brief description]. I've [what I fixed]. I'll include full details in this month's maintenance report."

Never disappear and then reappear with a fix. Clients hate uncertainty more than outages.

The 15-minute emergency flow

0-2 min:   Confirm outage (external tool + different network)
2-5 min:   Identify symptom type
5-7 min:   Check server resources + error logs
7-10 min:  Apply fix based on symptom
10-12 min: Verify site is up, test key pages
12-15 min: Contact client with status update

If not resolved by minute 15: contact hosting support, set maintenance mode, restore from backup.

Prevention: the monitoring setup that catches outages before clients call

I use a simple uptime monitor that pings every 5 minutes and sends an SMS/email alert if the site returns anything other than 200.

# wp-uptime-monitor.ps1 -- runs via Task Scheduler every 5 min
$sites = Get-Content "clients.json" | ConvertFrom-Json
foreach ($site in $sites) {
    $code = (Invoke-WebRequest -Uri $site.url -UseBasicParsing).StatusCode
    if ($code -ne 200) {
        Send-MailMessage -To "you@email.com" -Subject "DOWN: $($site.name)" -Body "Status: $code"
    }
}

This script is included in the automation bundle -- set it up once, it watches all client sites automatically.

The automation bundle includes the uptime monitor script (PowerShell + Bash), pre-update backup scripts, and post-update health checks:
WordPress Agency Automation Bundle

Free monthly checklist with emergency section:
WordPress Monthly Maintenance Checklist