Nine out of ten WordPress outages we see start with an update. A plugin, a theme, PHP itself. The site worked at 14:30, the update ran at 14:31, and at 14:35 the checkout is a white screen.
First: know that it is down
The worst version of this story is the one where you find out from a customer, hours later. An external monitor checking the start page and the checkout every minute, confirmed from a second location, turns "hours" into "two minutes".
Then, in this order
- Read the error. Since WordPress 5.2 a fatal error sends an e-mail to the admin address with the file and line. The file path usually names the plugin.
- Check
wp-content/debug.logif logging is on, or the server's PHP error log. - Deactivate the suspect – via the recovery-mode link in that e-mail, or by renaming its folder under
wp-content/plugins/over SFTP. The site comes back instantly if that was it. - Roll back to the previous version from wordpress.org's "Advanced view" while you wait for a fix.
- Only then clear caches and check the rest of the site.
What you could not see
External monitoring tells you that the site broke and when. It cannot tell you that plugin X was updated 60 seconds before the first fatal error – that information lives inside WordPress. This is the gap Ravnsight Detective, our WordPress plugin, is built to close: it records updates, errors and performance inside the site and Ravnsight lines them up with what the monitor saw. "Checkout down since 14:35, strongly correlated with the update of plugin X at 14:31" is a very different message from "HTTP 500".
Until then: monitor the pages that matter, not just the homepage, and keep the admin e-mail address one that a human reads.
