How we handle WordPress disasters — our actual incident runbook

The call comes in at 9:30 AM on a Monday. The client's WooCommerce store is down. They are getting a white screen. They have no idea when it broke. They were processing orders fine until some point yesterday. This is the scenario we have rehearsed, not because we enjoy rehearsing it, but because it has happened enough times that not having a process is negligent.

Over three years of managing WordPress sites for clients, we have built what we call our incident runbook. It is not glamorous. It is a structured checklist we follow every time something breaks so that we do not skip steps in a panic.

The first ten minutes

First step: establish the scope. Is the entire site down or is it a specific page or flow? Check the homepage, the product pages, the checkout. If it is only checkout, that is a WooCommerce or payment gateway issue, not a server issue. Second step: check server status. If we manage the hosting, we look at uptime monitoring first. If there is a server-level problem, that changes everything. Third step: check the PHP error log. On a white screen, the PHP log almost always tells you exactly what broke. It is not a mystery. It is usually a plugin update that introduced a fatal error or a PHP version mismatch.

While we are doing this, one person has already texted the client to say we are on it. Short message, no speculation. "We are looking at it now and will update you in 20 minutes." That one message reduces client anxiety significantly.

The hierarchy of fixes

If we can identify the broken plugin from the error log, we disable it via SFTP or by renaming the plugin folder directly, bypassing WordPress admin if admin is also broken. Site comes back up. We test the affected functionality. We investigate the plugin update or conflict at our own pace instead of under fire.

If it is not a plugin issue, we check if a recent theme update or core update was applied. We look at the deployment log if there was one. We look at the error log timestamp to correlate with any changes.

If we cannot identify the cause in 30 minutes, we restore from the most recent clean backup and investigate post-restore. The client is down, not us doing forensics. Get them back up first.

We document every incident in a shared log: what broke, when, why, how we fixed it, how long the site was down. This log has caught repeat patterns, specific plugins that cause trouble, a server configuration that needs attention. It turned reactive firefighting into preventive maintenance over time.