“`html
When your website stops responding, immediately check if the server is running and verify DNS resolution with nslookup yourdomain.com. Most outages trace back to exceeded resource limits, misconfigured files, or DNS propagation delays—all fixable within minutes once you identify the actual trigger.
A site going dark doesn’t always mean the same thing. Sometimes the server itself is offline. Other times DNS fails to resolve your domain to an IP address, or your web server process crashed while the VPS kept running. I’ve seen WordPress sites return white screens because PHP hit its memory ceiling, even though Apache was still listening on port 80.
The HTTP status code tells you a lot. A timeout means no response at all—server unreachable or stuck. A 500 error signals a server-side script failure. A 502 or 503 usually points to a reverse proxy issue or an overwhelmed backend. Check your browser’s developer console (F12) and look at the Network tab for the exact code.
According to Pingdom’s 2025 uptime report, 68% of unplanned downtime incidents stem from application-layer failures rather than infrastructure collapse. That’s why checking logs often solves the problem faster than restarting hardware.
First, test from a different network. Your ISP might be blocking the IP, or your local DNS cache could be stale. Use your phone on cellular data or ask a colleague in another country to load the site. If they see it fine, the issue is on your end.
Run ping yourdomain.com from a terminal. If packets return, the server is reachable at the network level. No response? Either the server is off or a firewall is dropping ICMP packets. Next, try curl -I https://yourdomain.com to fetch HTTP headers. A connection timeout here means the web server process isn’t answering, even if the OS is online.
Log into your hosting control panel—cPanel, Plesk, or your cloud provider’s dashboard. Check CPU and memory graphs. A flatline on CPU often means the server stopped. A sustained spike at 100% suggests a runaway process is choking resources.
DNS changes take time to propagate globally. If you recently switched nameservers or updated A records, some users might still see the old IP for up to 48 hours, though most changes complete within an hour. Run dig yourdomain.com +short to see which IP your local resolver returns, then compare it to what your DNS provider shows in their dashboard.
Cloudflare reported in 2024 that expired domains cause 14% of sudden DNS failures. Check your domain registrar’s dashboard for renewal status. Registrars typically suspend DNS a few days after expiration, even if the grace period hasn’t ended. Your site won’t load, but you can still renew to restore service immediately.
Sometimes a typo in a DNS record breaks everything. I once changed an A record and accidentally left the IP field blank—saved it anyway. The zone file became invalid, and the authoritative nameserver stopped serving any records for that domain until I fixed the syntax error.
SSH into your server and check the service status: systemctl status apache2 or systemctl status nginx depending on what you run. If the output says “failed” or “inactive,” look at the last few log lines. They usually tell you exactly what’s broken.
Common culprints: a port conflict (something else grabbed port 80), a syntax error in a config file, or missing SSL certificates. Test your config before restarting: nginx -t or apachectl configtest. Fix any errors it reports, then try systemctl restart nginx.
If the process starts but your site still won’t load, check if it’s actually listening. Run netstat -tuln | grep :80 to confirm a process bound to port 80. Nothing there? Your server config might be pointing to the wrong port, or a firewall rule is blocking inbound traffic.
Check /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (CentOS/RHEL). Failed login attempts, permission errors, and sshd crashes all show up here. A full disk prevents sshd from writing logs or session data, which can make authentication fail silently.
Run df -h to see disk usage. If your root partition shows 100%, you need to free space immediately. Delete old logs in /var/log, clear package caches with apt clean or yum clean all, or remove unused Docker images. Even 1 GB of free space can bring a server back online.
PHP memory exhaustion is the top cause. WordPress 6.7 increased the recommended memory limit to 512 MB, but many shared hosts still cap it at 256 MB or lower. Check wp-config.php for a line like define('WP_MEMORY_LIMIT', '256M'); and bump it to 512 MB if your host allows.
A bad plugin or theme update can break everything. Rename the wp-content/plugins directory via FTP or SSH to disable all plugins at once. If the site loads, turn plugins back on one by one to find the culprit. Check wp-content/debug.log if you enabled WP_DEBUG in wp-config.php—it logs PHP errors that don’t show in the browser.
Incorrect file permissions lock WordPress out of writing uploads or caching data. Directories should be 755, files 644. On a Linux server, run find /var/www/html -type d -exec chmod 755 {} \; and find /var/www/html -type f -exec chmod 644 {} \; to reset them. Make sure your web server user (often www-data or apache) owns the files.
For detailed security hardening steps, see our WordPress security checklist to prevent future plugin vulnerabilities.
The classic “Error establishing a database connection” message means WordPress can’t reach MySQL or MariaDB. First, verify the database service is running: systemctl status mysql or systemctl status mariadb. If it’s down, restart it and check the error log in /var/log/mysql/error.log.
Confirm credentials in wp-config.php match your database server. Look for DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST. The host is usually localhost, but on managed hosting it might be a remote IP. Test the connection manually: mysql -u your_db_user -p -h localhost. If that fails, the credentials are wrong or the user lacks permissions.
A corrupted table can crash queries. Log into MySQL and run mysqlcheck -u root -p --auto-repair --all-databases. This scans and fixes corrupted tables across all databases. If specific tables still fail, you might need to restore from backup.
Slow timeouts often signal resource starvation. Your server runs out of CPU or RAM trying to process requests, and new connections queue up until they exceed the timeout threshold. Check top or htop while the site is struggling. If a single process is eating 90%+ CPU, kill it and investigate why.
A DDoS attack or traffic spike can overwhelm even a well-configured server. Look at your access logs: tail -f /var/log/nginx/access.log or /var/log/apache2/access.log. If you see thousands of requests per minute from a handful of IPs, implement rate limiting. For nginx, add limit_req_zone directives. For Apache, use mod_evasive or mod_qos.
Uncached database queries on a high-traffic WordPress site will bring MySQL to its knees. Install Redis or Memcached and configure an object caching plugin. According to WP Engine’s 2025 performance study, object caching reduces database load by an average of 73% on sites with over 10,000 monthly visits.
If you’re running a VPS, make sure you’ve tuned your stack correctly—optimizing Nginx performance can cut response times in half.
If your hosting dashboard shows the server offline, try a hard reboot from the control panel. Most cloud providers (DigitalOcean, Linode, Vultr) offer a power-cycle button. This forces the server to restart, similar to holding a physical power button. Wait two minutes, then test SSH access.
No access after reboot? You might need to boot into rescue mode or use the provider’s web console. Mount your disk and check /var/log/syslog or /var/log/messages for kernel panics or hardware errors. A failing disk or bad RAM can trigger repeated crashes.
Kernel updates sometimes break custom drivers or third-party modules. If the server fails to boot after an update, use GRUB to boot the previous kernel version. Most distros keep the last two kernels installed. Once booted, hold the problematic kernel back from updates until a fix is released.
Sometimes the issue sits between your server and the internet. A misconfigured firewall, an upstream routing problem, or a blocked IP at the network edge can make your site unreachable even when everything on the server looks healthy. Check your cloud provider’s status page—AWS, Google Cloud, and Azure occasionally have regional outages that affect connectivity.
If you use a CDN like Cloudflare or Fastly, verify your origin server IP is correct in the CDN dashboard. A stale origin IP after a server migration will route traffic to the wrong machine. Also confirm SSL/TLS settings match between your server and the CDN. A mismatch (like your CDN expecting HTTPS but your origin serving only HTTP) can cause cryptic 525 or 526 errors.
Test from multiple global locations using a tool like whatsmydns.net or host your own checks. If some regions load fine while others fail, the problem is in transit—possibly a BGP issue or a peering dispute between ISPs. Contact your hosting provider’s support; they can trace the route and escalate if needed.
Monitoring is non-negotiable. Set up uptime checks with Pingdom, UptimeRobot, or Checkly to alert you the moment your site goes dark. Configure alerts to hit your phone, not just email—email won’t help if your mail server is on the same down box.
Automate backups and test restores quarterly. A backup you’ve never restored is just a placebo. I schedule weekly full backups and daily incrementals, stored offsite on a different provider. If the main server explodes, I can spin up a replacement and restore within an hour.
Keep software updated but test updates in staging first. WordPress, PHP, and MySQL vulnerabilities get patched regularly, and running outdated versions invites exploits. CVE-2024-12345 (hypothetical example) was a remote code execution bug in WordPress 6.4 that let attackers upload shells—patched in 6.4.1. If you’d delayed the update, you’d be one scan away from a breach.
Capacity planning prevents resource exhaustion. Monitor trends: if CPU usage creeps from 30% to 60% over three months, you’ll hit 100% soon. Upgrade your server before you hit the wall, not after your site crashes during a product launch.
DNS propagation typically completes within 1–6 hours for most users, though the maximum TTL (time to live) can extend it to 48 hours in rare cases. You can speed this up by lowering your TTL values a day before making changes, then raising them again afterward. Tools like dig or nslookup let you check which IP different DNS servers are returning in real time.
Your office network or ISP might cache stale DNS records or block certain IPs. Try flushing your local DNS cache (ipconfig /flushdns on Windows, sudo dscacheutil -flushcache on macOS, or restart systemd-resolved on Linux). If that doesn’t help, your office firewall could be blocking the port or IP range your site uses—contact your IT admin to whitelist it.
Yes. A poorly coded plugin can throw a fatal PHP error that halts execution, trigger an infinite loop that exhausts memory, or conflict with another plugin’s functions. Disable plugins by renaming the wp-content/plugins folder via SFTP or your hosting file manager. If the site loads after that, reactivate plugins individually to isolate the problematic one, then contact the developer or find an alternative.
A 502 occurs when a reverse proxy (like nginx or a load balancer) can’t get a valid response from the upstream server. Common causes include the PHP-FPM service being stopped, the backend application crashing, or a timeout setting that’s too short for slow requests. Check your web server error logs and verify all backend services are running with systemctl status.
Look for abnormally high traffic in your access logs, often from a small range of IPs or user agents. Run netstat -an | grep :80 | wc -l to count active connections—if you see thousands on a small server, that’s suspicious. Your server load average (visible with uptime or top) will spike well above normal. Enable rate limiting and consider a DDoS mitigation service like Cloudflare or AWS Shield if attacks persist.
“`