The Weekend Crash

The client ran the website for a professional membership organisation. Their annual conference was approaching and registration had opened four days earlier. Several hundred members were expected to register over the weekend.

The site went down on a Friday evening at approximately 18:40. The admin panel was inaccessible. The front-end was returning a PHP fatal error. The previous developer, who had done some work on the site earlier that week, was not reachable.

The client contacted me at 19:03. They had already been down for 23 minutes. Conference registrations were failing, and members were beginning to contact the organisation directly.

The PHP fatal error message, once retrieved from the server error logs via SFTP, was an uncaught exception from a plugin — a type mismatch error on a function that expected an array but was receiving null.

The call stack pointed to a recent plugin update. Cross-referencing the file modification timestamps confirmed: the plugin in question had been auto-updated at 18:37, three minutes before the site went down. The update introduced a breaking change that the plugin developer had not tested against the PHP version on this server.

The previous developer's work earlier in the week was unrelated. The cause was a plugin update with a compatibility regression.

Because the admin panel was inaccessible, the recovery had to be done via SFTP and WP-CLI directly.

The site was restored at 19:50 — 47 minutes after first contact, 70 minutes after the outage began. Conference registration continued over the weekend without further incident. No registration data was lost.

The client had not previously been aware that WordPress auto-updates could take their site down without warning. Following the incident, we implemented a staged update process — updates are now applied to a staging environment and verified before being applied to the live site.