You clicked “Update,” and a few seconds later the site answers with a white screen or “There has been a critical error.” The silver lining: when a problem starts right after an update, you have a strong lead. Below we move methodically from symptom to confirmed cause.
1. Find out what updated – and when
Start with the timeline. Go to Tools → Site Health or check Dashboard → Updates. If you run an activity log (such as WP Activity Log), you’ll see exactly which plugin updated and at what time. Note the timestamp – it should match when the site stopped working. An error that begins minutes after an update is strongly correlated with that update, even if you haven’t proven it yet.
2. Turn on the debug log
By default WordPress hides errors from visitors. Open wp-config.php over FTP or the file manager and add these lines above /* That's all, stop editing! */:
define( 'WP_DEBUG', true );define( 'WP_DEBUG_LOG', true );define( 'WP_DEBUG_DISPLAY', false );
Reload the page that crashes, then open wp-content/debug.log. This is where the truth lives.
3. Read the fatal error and stack trace
A typical PHP fatal error looks like this:
PHP Fatal error: Uncaught Error: Call to undefined function acme_helper() in /wp-content/plugins/acme-forms/includes/render.php:212
The last line points to the file and plugin folder where the error was thrown. If a Stack trace follows, you can read the call chain backwards. For a clean PHP fatal error, the plugin folder in that path (here acme-forms) is where the code broke – your prime suspect, and the first thing you test in step 5.
When the error points to a different plugin than the one you updated
Sometimes you updated plugin A but the trace points to plugin B. That usually means a dependency conflict – A removed or changed a function B relied on. Still, start with whatever just changed.
Locked out? WordPress may already have e-mailed you
Since WordPress 5.2, a fatal error sends an e-mail to the admin address (“Your Site is Experiencing a Technical Issue”) with a recovery-mode link. It logs you into wp-admin with the failing plugin paused, so you can roll it back from Dashboard → Updates without FTP. No e-mail? The site may have no working mail delivery – renaming the folder, as below, always works.
4. Roll back the offending plugin
Locked out of the admin panel? Rename the plugin’s folder over FTP, for example acme-forms to acme-forms.off. WordPress deactivates it automatically and you’ll likely regain access to wp-admin. Then install an earlier version with the WP Rollback plugin, or download it from the “Advanced View” tab on the plugin’s wordpress.org page and install manually.
5. Confirm that was the cause
Reload the site. If it works again with the restored plugin, the cause is confirmed. Clear all caches first – page cache, object cache and any CDN cache – so you’re not looking at a stale version. Also check that your PHP version is supported by the new plugin release; many fatals after an update happen because the plugin needs newer PHP than the server runs.
When the plugin isn’t the whole story
If the rollback doesn’t bring the site back, look at what the update changed around the plugin:
- Memory.
Allowed memory size of … bytes exhaustedmeans the new version needs more memory. RaiseWP_MEMORY_LIMITin wp-config.php (for example to256M); if your host caps it, raise it in php.ini or the control panel. - PHP version. A plugin that now requires PHP 8.1 on a server running 7.4 – or an old plugin meeting a newer PHP – fails the same way. Check Tools → Site Health → Info → Server, and test a PHP switch on staging first.
- Object cache. A stale or broken object-cache drop-in can keep serving the error after the real problem is gone. Flush it, or disable it briefly, before you draw conclusions.
6. Fix it properly
A rollback is a temporary fix. Read the plugin’s changelog, test the new version in a staging environment, and report the bug to the developer. Once a fix ships, update again – this time on staging first.
When “what changed right before” should be instant
This entire hunt comes down to one question: what happened right before it broke? That’s exactly where Ravnsight’s Detective saves time. Detective records every plugin, theme and core update, groups the PHP fatal, and attributes it to the plugin the stack trace points to – all on one shared timeline. Instead of manually cross-referencing activity logs against debug.log, you see immediately that “the error started three seconds after acme-forms updated.”
And because a crashed site doesn’t always log for itself – if PHP dies early, nothing may reach debug.log – it’s worth monitoring from the outside too. Ravnsight’s uptime monitoring notices the downtime from an external vantage point and alerts you before a customer does, so you can start troubleshooting minutes after – not hours after – the update goes wrong.
