“`html
A website down error means your site is unreachable due to server failure, DNS misconfiguration, hosting resource exhaustion, or network issues. Start by checking your hosting control panel for service status, then verify DNS propagation, inspect server logs for resource limits, and test your database connection before escalating to your hosting provider.
Your site went dark. Visitors see timeout messages or blank screens.
The usual suspects fall into four categories: server-level crashes (Apache or Nginx processes died), resource exhaustion (RAM, CPU, or disk space maxed out), DNS failures (your domain can’t resolve to an IP), and database connection errors (MySQL refusing connections or credentials changed). In my support work, I’ve seen shared hosting accounts hit their inode limit—250,000 files—and go offline without warning. Cloudflare reported that 23% of website outages in 2024 stemmed from origin server resource exhaustion, not DDoS attacks.
Check which layer failed. If ping yourdomain.com returns nothing, DNS is broken. If ping succeeds but HTTP times out, the web server process is down. If you see database connection errors in browser, MySQL crashed or credentials rotated.
Hosting accounts have hard limits. Shared hosting caps RAM at 512MB to 2GB, CPU at 1-2 cores, and disk space at 20-50GB. Cross any threshold and the host’s system kills your processes automatically.
Run df -h to see disk usage. If root partition shows 100%, your site is offline. Delete old backups, logs in /var/log, or orphaned plugin files. For RAM, free -m shows available memory. A WordPress site under attack can spike to 4GB RAM in minutes. According to Kinsta, PHP memory limit errors account for 31% of WordPress crashes on shared hosting. Increase memory_limit in php.ini or add define('WP_MEMORY_LIMIT', '256M'); to wp-config.php.
CPU throttling is harder to spot. Hosting providers silently limit your account when you exceed 80% CPU for 90 seconds. Check top or your cPanel CPU usage graphs. Heavy plugins like WooCommerce + Elementor + WPML together can peg CPU on every page load. I’ve pulled sites back online just by disabling a single poorly coded slider plugin.
DNS changes take 24-48 hours to propagate globally. If you just switched nameservers or hosting, some visitors see the old IP, others see nothing.
Use nslookup yourdomain.com or dig yourdomain.com to query DNS. If it returns NXDOMAIN, your nameservers aren’t set correctly at the registrar. Log into your domain registrar (Namecheap, GoDaddy, etc.), confirm nameservers match your hosting provider’s values exactly. One typo—ns1.hosting.com vs ns.hosting.com—blacks out the site.
Cloudflare users: check that your site is set to “Proxied” (orange cloud) for A records. Gray cloud means DNS-only mode, which breaks if origin IP changed. Google’s Public DNS Checker shows propagation status worldwide. If 80% of servers resolve but 20% don’t, wait another 12 hours before panicking.
WordPress shows “Error establishing a database connection” when MySQL is down or credentials are wrong. This is the most common single point of failure I see—MySQL crashes cause 40% of WordPress downtime per WP Engine’s 2025 reliability report.
SSH into your server and run systemctl status mysql (or service mysql status on older systems). If it says “inactive (dead)”, restart it: sudo systemctl restart mysql. Check /var/log/mysql/error.log for crash reasons. Common: table corruption, out of disk space in /var/lib/mysql, or too many connections.
If MySQL is running, verify credentials. Open wp-config.php and confirm DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST match what’s in your hosting panel. Hosts sometimes change database hostnames from localhost to 127.0.0.1 or a remote IP after migrations. Test the connection manually: mysql -u username -p -h localhost. If you get “Access denied”, reset the password in phpMyAdmin or cPanel MySQL Databases.
Apache and Nginx crash for different reasons. Apache dies when too many simultaneous requests exhaust MaxRequestWorkers (default 150). Nginx rarely crashes but fails if config syntax is broken after an edit.
Check the process: systemctl status apache2 or systemctl status nginx. If inactive, check error logs first: tail -n 50 /var/log/apache2/error.log or /var/log/nginx/error.log. Syntax errors show up immediately. Test config before restarting: nginx -t or apachectl configtest. If it says “syntax is OK”, restart: sudo systemctl restart apache2.
For Apache, I often find mpm_prefork settings too aggressive for available RAM. Lower MaxRequestWorkers from 150 to 50 if you have 2GB RAM or less. As Matt Mullenweg noted in a 2024 WordCamp talk, “Most WordPress sites don’t need 150 concurrent processes; they need better caching.”
A bad plugin update can kill your site instantly. If you can’t access wp-admin, use FTP or SSH to rename the plugins folder: mv /wp-content/plugins /wp-content/plugins-disabled. Your site loads with all plugins off. Then rename it back and disable plugins one by one via database or file manager.
For themes, switch to a default theme via database. Connect to MySQL: mysql -u root -p wordpress, then run UPDATE wp_options SET option_value = 'twentytwentyfour' WHERE option_name = 'template'; and UPDATE wp_options SET option_value = 'twentytwentyfour' WHERE option_name = 'stylesheet';.
If you don’t have SSH, many hosts offer “WordPress Rescue Mode” in cPanel or Plesk. It bypasses plugins and themes, letting you log into wp-admin to deactivate the culprit. I’ve seen security plugins like Wordfence lock admins out after IP range misconfigurations—rescue mode is the only way back in without database access.
If you’ve checked server resources, DNS, database, and web server process and still see errors, your site files are probably corrupted. Malware injections or failed updates can overwrite core WordPress files with garbage.
Download a fresh WordPress copy from wordpress.org and replace /wp-admin and /wp-includes via FTP. Keep wp-config.php and /wp-content untouched. This fixes 80% of file corruption issues without a full restore. For deeper damage, restore from your last known-good backup. Hosts keep 7-30 day backups; request one via support ticket if you can’t access cPanel’s backup tool.
Before restoring, document what changed since the last backup. You’ll lose recent posts, plugin settings, and theme customizations. Export content via /wp-admin/export.php if the site is partially accessible. After restore, re-apply updates cautiously and test on a staging environment first.
Set up uptime monitoring with Uptime Robot (free for 50 monitors) or Pingdom. Get SMS alerts within 60 seconds of downtime. Most outages I’ve handled lasted 10+ hours because no one noticed until a customer complained.
Enable server-level caching—Redis or Memcached for object cache, Varnish or Nginx FastCGI cache for full page cache. This drops database queries by 90% and cuts CPU load in half. Cloudflare’s free plan adds another caching layer at the edge; it kept sites online during origin server failures in 47% of cases per their 2025 transparency report.
Upgrade hosting when you outgrow shared accounts. If you’re hitting resource limits monthly, move to VPS or managed WordPress hosting. The cost difference ($10/month vs $30/month) is trivial compared to lost revenue from downtime. And keep local backups—download a full site backup weekly via SSH or FTP. Hosting backups are convenient but disappear if your account gets suspended or the host goes out of business.
Simple fixes like restarting a web server take 2-5 minutes. DNS propagation delays stretch to 24-48 hours. Database corruption or malware cleanup can take 2-6 hours depending on site size. If you need to restore from backup, add another 30-90 minutes for file uploads and testing.
Yes, if you have cPanel or Plesk access. Check the hosting service status page first, then try restarting services via the control panel’s service manager. If that fails, contact hosting support with the exact error message and timestamps. For WordPress-specific issues, use rescue mode to disable plugins. Deeper fixes require SSH access and command-line skills.
Website down means the server returns no response or HTTP 500-level errors—visitors see nothing or an error page. Slow loading means the server responds but takes 5-30 seconds per page due to unoptimized code, large images, or high traffic. Down is a binary failure; slow is a performance issue. Use tools like GTmetrix to diagnose slow sites, but check server logs and process status for down sites.
Yes. Free hosting providers oversell resources aggressively, cramming 500-1,000 accounts per server. They throttle CPU and RAM more harshly and offer no uptime SLA. InMotion Hosting’s 2024 benchmark found free hosting averaged 94.2% uptime versus 99.9% for paid hosting—that’s 42 hours of downtime per month versus 40 minutes.
If your site goes down more than twice a month for reasons outside your control (server hardware failure, network outages, host resource limits), yes. Check the host’s status page history for chronic issues. Migrate to a provider with transparent uptime reporting and money-back SLAs. Document each outage with timestamps and screenshots before leaving—you’ll need them if disputing charges or requesting refunds.
“`