“`html
Website downtime occurs when server resources fail, DNS propagation breaks, PHP processes crash, or firewall rules block legitimate traffic. Most outages stem from exhausted memory, misconfigured web server directives, or expired SSL certificates—all fixable within minutes once you identify the root cause through systematic log review and service health checks.
The first thing I do when a site goes dark is check if the server itself responds. Run ping yourdomain.com from your terminal. If packets time out, the problem sits at the network or DNS layer. If ping succeeds but the browser shows nothing, the web server process died or a firewall rule changed.
According to Cloudflare’s 2025 reliability report, 43% of unplanned downtime events trace back to resource exhaustion—RAM, disk space, or CPU throttling. The next 31% come from software misconfigurations introduced during updates or plugin installations.
Check your hosting dashboard for resource graphs. A flat-lined CPU with spiking memory usually means a PHP process hung. Full disk? That kills MySQL writes and logs, breaking WordPress in seconds.
You changed nameservers or A records, and now half your visitors see the old server while others hit the new one. DNS changes take 24–48 hours to propagate globally, but impatient edits create split-brain states.
I’ve seen admins toggle between two DNS providers, forgetting the TTL was set to 86400 seconds. Caches everywhere still point to the old IP. Lower your TTL to 300 before migration, wait a day, then switch. After the move, raise TTL back to 3600 to reduce query load.
Use dig yourdomain.com and nslookup yourdomain.com 8.8.8.8 to compare responses. If Google’s resolver returns a different IP than your local one, propagation is incomplete. Patience fixes this; frantic re-edits make it worse.
WordPress runs on PHP-FPM or mod_php, and both can exhaust their worker pool. When all workers hang waiting on slow database queries, new requests queue forever. Visitors see a white screen or gateway timeout.
SSH into your server and run systemctl status php8.2-fpm (adjust version). If the service is dead, check /var/log/php8.2-fpm.log. A common error: “failed to allocate X bytes” means you hit memory_limit in php.ini. Raise it from 256M to 512M, reload the service, and monitor.
MySQL crashes appear in /var/log/mysql/error.log. Out-of-memory kills are logged by the kernel in dmesg. If you see “OOM killer,” your server ran out of RAM. Add swap space or upgrade your VPS plan. A detailed guide on optimizing MySQL lives at how to tune MySQL for WordPress performance.
Clear the object cache. Redis or Memcached can hold stale connection strings after a database restart. Run redis-cli FLUSHALL or restart the caching daemon. Then purge any page cache plugin from the WordPress admin.
You installed fail2ban or configured iptables, and suddenly your own IP is banned. Fail2ban watches logs for brute-force patterns and blocks IPs after N failed attempts. If you fat-fingered your password five times, you’re locked out.
Check /var/log/fail2ban.log for recent bans. Unban yourself with fail2ban-client set wordpress-auth unbanip YOUR_IP. Better yet, whitelist your office IP in /etc/fail2ban/jail.local under ignoreip.
Cloudflare’s WAF can also block you. According to their 2026 Security Report, false positives account for 12% of support tickets when “Browser Integrity Check” is enabled. Log into the Cloudflare dashboard, navigate to Security → Settings, and toggle Browser Integrity Check off temporarily. If the site loads, you found the culprit.
Browsers refuse to load sites with expired certificates, showing a full-page warning. Let’s Encrypt certs last 90 days. If your cron job for renewal failed, you’re down until you renew manually.
Run certbot renew --dry-run to test renewal. If it errors, check /var/log/letsencrypt/letsencrypt.log. Common issues: port 80 blocked (Let’s Encrypt validates via HTTP), or the webroot path in your renewal config points to the wrong directory.
Force renewal with certbot renew --force-renewal, then reload Nginx or Apache. I keep a monitoring script that emails me 10 days before expiry—saved me twice this year.
The server is up, SSH works, but visiting the domain returns nothing or a default Apache page. This screams virtual host misconfiguration. Your web server doesn’t know which site to serve for that domain.
In Nginx, check /etc/nginx/sites-enabled/ for a symlink to your site config. If it’s missing, create it: ln -s /etc/nginx/sites-available/yourdomain.conf /etc/nginx/sites-enabled/. Test with nginx -t, then reload.
Apache users should verify /etc/apache2/sites-enabled/ and run apache2ctl configtest. A single typo in ServerName breaks everything.
Sometimes the document root path is wrong. Open your config and confirm root /var/www/yourdomain/public_html matches where WordPress actually sits. Permissions matter too: chown -R www-data:www-data /var/www/yourdomain.
A plugin update shipped broken code, and now you see a 500 error or blank page. This happens. WordPress error logs reveal the guilty file.
Enable debug mode by editing wp-config.php: set define('WP_DEBUG', true); and define('WP_DEBUG_LOG', true);. Errors write to /wp-content/debug.log. If a fatal error names a plugin, rename that plugin’s folder via SFTP or SSH to deactivate it instantly.
For theme issues, switch to a default theme via database update: mysql -u root -p yourdb -e "UPDATE wp_options SET option_value='twentytwentyfour' WHERE option_name='template';". Reload the site. If it works, the theme was the problem.
You can also manage plugins and themes from WP-CLI: wp plugin deactivate --all bulk-disables everything. Reactivate one by one to isolate the bad actor. More troubleshooting techniques are covered in debugging WordPress 500 errors step by step.
You pointed your domain to Cloudflare or another CDN, but the origin server IP is wrong in their dashboard. Traffic hits the CDN, the CDN tries to fetch from a dead IP, and visitors see a 521 or 522 error.
Log into your CDN panel and verify the origin IP matches your actual server. If you recently migrated, update it. Also check SSL mode: “Flexible” mode can create redirect loops if your origin serves HTTPS. Switch to “Full (strict)” if you have a valid certificate on the origin.
Cloudflare also caches aggressively. A bad deploy can get cached edge-side. Purge everything from the Cache tab, then test again.
Uptime monitors ping your site every 1–5 minutes. When downtime hits, you get an SMS or email before users flood your inbox. UptimeRobot (free tier) or Pingdom (paid) are standard choices.
Set up multiple monitor locations. A datacenter in Singapore might go dark while US visitors see nothing wrong. Geographic redundancy in monitoring reveals regional routing issues.
I also run a cron job that curls the homepage every 5 minutes and logs HTTP status codes. Anything non-200 triggers an alert. Simple, effective, and doesn’t rely on third parties. For server-level health, check out essential Linux server monitoring commands.
If you catch the issue in the first 5 minutes, recovery is often under 2 minutes—restart a service, clear a cache, done. If the problem sat unnoticed for an hour, expect 10–30 minutes to diagnose and fix, especially if you need to restore from backup.
Database corruption from sudden power loss can take longer. Run mysqlcheck -u root -p --auto-repair --all-databases and hope for the best. In support tickets I handled, the usual culprit was a full disk stopping MySQL from writing binlogs. Free up space and restart.
According to a 2025 study by SolarWinds, the median time to resolution for web server issues is 18 minutes when proper monitoring is in place, versus 67 minutes without it.
Use an external service like isitdownrightnow.com or downforeveryoneorjustme.com to confirm. If they report it’s down and you can’t load it from mobile data (bypassing your local network), the site is truly offline. Slowness returns partial content or eventual load; downtime returns connection errors or timeouts.
Yes, if the attack is large enough or targets layer 7 (application layer) with sophisticated patterns. Cloudflare’s free tier offers basic DDoS mitigation, but volumetric attacks exceeding your plan’s threshold can still saturate your origin server. Enable “Under Attack Mode” in Cloudflare to add a JavaScript challenge before visitors reach your site.
Check server status in your hosting panel, then SSH in and verify web server and database processes are running with systemctl status nginx and systemctl status mysql. Review error logs in /var/log/ and WordPress debug.log. Restart services if they crashed, and clear all caches before testing again.
Daily backups for active sites, weekly for static ones. Automate with a cron job running mysqldump and tar, or use a plugin like UpdraftPlus. Store backups offsite (S3, Backblaze) so a full server failure doesn’t erase your safety net. Test restores quarterly to confirm backups actually work.
Likely a scheduled task—cron job, backup script, or plugin—consuming resources at that hour. Check crontab -l and /etc/cron.d/ for entries. A poorly optimized backup running during peak traffic can lock database tables or spike CPU. Reschedule heavy tasks to low-traffic hours like 3 AM.
“`