My WordPress Site Is Down: There Has Been a Critical Error

What 'There Has Been a Critical Error' Actually Means

Somewhere in your stack - almost always a plugin or the theme - a line of PHP failed hard enough that WordPress could not keep running. The fatal-error handler caught it and printed this message instead of a white page. That is the whole error. Your files are still on disk, your database is still there, your content is fine. One extension crashed and took the entire site down with it.

The Pattern

A plugin updates. Or your host bumps the PHP version. Or someone edits a file through the theme editor. The very next request answers with "There has been a critical error on this website." The frontend is down. wp-login.php is down too, so you cannot deactivate the suspect plugin - and the email that could get you back in goes to whatever address happens to sit in Settings → General.

The older flavor of the same crash is the White Screen of Death: the fatal fires before WordPress can render anything, so the browser gets an empty page. Same cause, less information. Both come from the same place, and both are covered below.

What WordPress Does Next - and Where It Stalls

Since WordPress 5.2, core has a real answer. When the fatal fires, the fatal-error handler detects it and emails a Recovery Mode link to the site's admin address. Click the link, log in again, and Recovery Mode pauses the broken extension - the site comes back with the plugin deactivated and a notice naming it. The mechanism is solid. The delivery is the weak part.

The link goes to whatever email sits in Settings → General - often a mailbox nobody reads
wp_mail() can be slow, spam-filtered, or switched off by the host entirely
The site stays down while you wait for a message that may never land
Every minute of waiting is another minute of error page for your visitors

A logged-in administrator goes straight to the signed Recovery Mode URL - no email round-trip
You still prove it is you: core's re-login gate stays in place
The broken plugin gets paused by core's own handler on the next request
A white screen becomes a real error page instead of an empty response

Same destination either way. The drop-in only removes the slowest, least reliable step from the middle of it.

What the Fatal Error Recovery Drop-ins Do

Two drop-ins deploy into wp-content when WP Multitool activates and stay there until you deactivate the plugin. There is no toggle and nothing to configure - a site cannot lose its crash recovery because someone flipped a setting off.

File	What it does
`fatal-error-handler.php`	Overrides core's fatal-error handler. When a logged-in administrator hits a plugin or theme fatal, it builds core's signed Recovery Mode URL on the spot and sends you to the login gate - skipping the email entirely
`php-error.php`	Renders the error itself. A fatal that used to end in a blank body now produces WordPress's real "critical error" page, so you always get a visible response

After you re-enter your password, the next crash goes through core's own handler, which pauses the offending extension. That pause is what brings the site back - my drop-in removes the wait between the crash and the recovery link. The URL is core's signed one; nothing about it leaks to your visitors.

What It Will Not Do - Read This Before You Rely On It

Logged-out visitors see the same error page either way. The site is down for them until the broken extension is paused. Handing strangers a recovery link would hand them your admin panel, so only a logged-in admin ever gets one.
Plugin and theme fatals only. A crash inside WordPress core, a drop-in, or a broken wp-config.php cannot be paused by Recovery Mode, so you get the plain error page.
No multisite. On a network install the drop-in steps aside and core handles the crash the default way.
It is not a backup. Pausing a broken plugin restores nothing - if the crash corrupted data, you need your host backup or a real one.
It does not prevent the crash. The bad code still runs and still fails. You get back in faster, with the culprit already named.
A dead database or a host outage is below this layer. WordPress dies before the handler loads, so there is nothing to intercept.

Broke wp-config.php itself?

Wrong database credentials or a bad edit kills WordPress before any handler loads. For that case Config Manager (Pro) ships a WP-CLI rescue command that restores a wp-config backup without booting WordPress at all - it works with the database completely unreachable.

Back In? Now See What Actually Broke

Recovery Mode names the extension it paused. The error that killed the site is in debug.log - if you have WP_DEBUG_LOG on - and a busy site can write hundreds of near-identical lines per request, so the fatal line sits under a pile of repeats.

Debug Log Guard (Pro) reads the log without loading it. It groups the repeats into a table - message, count, source plugin or theme, first and last seen - and streams the tail, so a multi-gigabyte log opens in seconds instead of crashing your editor. The line that took the site down floats to the top, already attributed to its source.

Back in and want the proof of what broke? Debug Log Guard turns the log into a grouped table with the culprit named.

Pro starts at $79/year →

WordPress Site Down FAQ

Why does my WordPress site say "There has been a critical error on this website"?

A PHP fatal - almost always inside a plugin or the theme - stopped the request. WordPress caught it in a shutdown handler and printed this message instead of a white page. Your files and database are intact; one extension crashed and took the site with it.

How do I get back into wp-admin when the site is down?

WordPress emails a Recovery Mode link to the site's admin address - click it, log in again, and the broken plugin gets paused. With WP Multitool's drop-ins, a logged-in administrator is sent straight to that signed Recovery Mode URL when the fatal happens, so there is no email to wait for.

The WordPress recovery mode email never arrived - now what?

Check spam, then check which address sits in Settings → General - it is often a mailbox nobody reads, and some hosts slow down or block wp_mail() outright. The fatal error recovery drop-in builds the signed URL on the spot for a logged-in admin instead of mailing it, so the flow cannot stall on email.

Is my site gone for good? Was I hacked?

Almost never. A critical error after an update, a PHP bump, or a file edit is one bad extension, not a hack and not lost data. Recovery Mode pauses the offender and the site comes back; your content, files, and database are untouched.

Does the recovery drop-in fix the error?

No - it gets you into Recovery Mode faster and the broken extension gets paused by core's own handler. The plugin that crashed still needs updating, replacing, or a bug report to its author. The drop-in buys you access and a name, not a patch.

Does fatal error recovery work on multisite?

No. On a network install the drop-in steps aside and WordPress handles the crash the default way - the recovery email to the admin address. Single-site installs get the direct redirect.

What about a white screen with no error message at all?

That is the White Screen of Death - a fatal that fires before WordPress can render its error page. WP Multitool's php-error.php drop-in makes sure the crash still produces the real "critical error" page, so you always see something instead of an empty response.