Incident response · WP site down

If your site is broken right now, this is the order to investigate in. Saves the average reader ~45 minutes of panic-debugging.

The order

1. Check the host’s status page first. 30% of “site down” incidents are host-side outages. Don’t waste time debugging your code if Kinsta / WP Engine is down.
2. Check DNS. Resolve the domain via dig or nslookup. Domain expired or DNS misconfigured is the second-most-common cause.
3. Check SSL cert expiry. If the cert expired, browser shows a security warning that looks like “site is down.” Let’s Encrypt auto-renewal can fail silently.
4. Check the most recent deploy / plugin update. 90% of “broken after a change” incidents revert cleanly. Roll back first; debug second.
5. Check error logs. WP-Admin Tools > Site Health, then the host’s PHP error log, then the web server access log.
6. Check disk space. A full disk presents as a 500 error with no useful log entry. df -h via SSH or the host’s control panel.
7. Check database connectivity. If wp-config.php DB credentials changed (or the DB is at capacity), the “establishing a database connection” error appears.
8. Restore from backup. If steps 1 — 7 don’t reveal the cause, restore yesterday’s backup. Debug forensically afterward.

License

MIT.