There Has Been a Critical Error on This Website: Finding What WordPress Is Hiding

There has been a critical error on this website means PHP hit a fatal error and WordPress caught it before the raw error reached your visitors. The details are not gone — they are deliberately hidden, and there are three places to find them.

This message replaced the old white screen of death, and it is a genuine improvement: WordPress now catches the fatal error, shows something civil, and often emails the site administrator with the specifics. The problem is that the email frequently does not arrive, which leaves you with a polite message and no information.

Table of contents

• Check the email first
• Turn the log on
• Check the server error log too
• When you are locked out of wp-admin
• The causes, roughly by frequency
• Reducing how often this happens
• How this fits the rest of the stack
• FAQ

Check the email first

When WordPress catches a fatal error, it attempts to email the address in Settings, General to the administration email address. That email contains the plugin or theme responsible, the file, and the line number — the entire diagnosis, delivered.

It also contains a recovery mode link. That link logs you into wp-admin with the offending plugin or theme paused, which gets you into the dashboard on a site that is otherwise completely inaccessible.

Check spam. This email is sent from your site’s domain by PHP mail, which is exactly the profile that gets filtered.

When the email never arrives — which is common, because many hosts do not have working outbound mail configured — you fall through to the log.

Turn the log on

In wp-config.php, above the line that says to stop editing:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Reload the site to trigger the error again, then read wp-content/debug.log. The last entry is your answer and it is usually unambiguous:

PHP Fatal error: Uncaught Error: Call to undefined function some_function()
in /wp-content/plugins/example-plugin/init.php:88
Stack trace:
#0 /wp-includes/class-wp-hook.php(324): example_init()

Read the first file path in the trace, not the last. The stack shows WordPress core calling into the plugin, so core files appear in the trace without being at fault. The path under wp-content is the culprit.

WP_DEBUG_DISPLAY false is not optional on a live site — it keeps the stack trace, which includes absolute server paths, out of the page visitors see. And turn all three off when you are finished, because a readable debug.log is an information leak.

If no debug.log appears at all, wp-content is not writable by the web server. Check permissions, or set WP_DEBUG_LOG to an explicit writable path instead of true.

Check the server error log too

Some fatal errors happen before WordPress is loaded enough to write its own log — a syntax error in wp-config.php, a missing core file, or PHP running out of memory during bootstrap. In those cases debug.log stays empty and the answer is in the server’s PHP error log.

Where that lives depends on the host, but the usual suspects are an error_log file in the site root or the document root, or a logs directory in your hosting panel. The memory case is distinctive and worth recognising:

PHP Fatal error: Allowed memory size of 134217728 bytes exhausted
(tried to allocate 20480 bytes)

That is not a code bug in the usual sense — it is a plugin doing something expensive on a site that has outgrown its memory limit. Raising WP_MEMORY_LIMIT buys time; finding which plugin allocates that much is the actual fix.

When you are locked out of wp-admin

A fatal error on the front end often takes the dashboard with it. Deactivate plugins from outside WordPress instead:

1. Using a file manager or SFTP, rename wp-content/plugins to wp-content/plugins-off.
2. Load the site. If it works, a plugin is responsible.
3. Rename the folder back. All plugins are now deactivated in the database.
4. Log in and reactivate one at a time, loading the front end after each, until it breaks.

If deactivating everything does not help, the theme is next. Rename the active theme’s folder and WordPress falls back to a default theme.

With WP-CLI, both are single commands and much faster:

wp plugin deactivate --all
wp theme activate twentytwentyfour

WP-CLI is worth having available precisely for this situation — it works when the site does not, because it bypasses the front end entirely.

The causes, roughly by frequency

Once you have the error text, it will be one of these:

• Plugin or theme incompatible with the PHP version. A host upgrades PHP, code using syntax removed in PHP 8 stops parsing. Nothing on your side changed, which makes it feel inexplicable.
• Plugin incompatible with the WordPress version. A core update removed or changed a function a plugin called. Same shape, different trigger.
• Two plugins conflicting. Both work alone, neither works with the other. Usually a function name collision or a filter one plugin depends on that another removes.
• Memory exhaustion. Not a crash so much as a ceiling. Shows up under load or on admin pages that process a lot of data.
• A corrupted file from a partial update. An update interrupted halfway leaves a truncated file. Reinstalling the plugin or core fixes it.

The first two are the majority, and they share a property worth internalising: the change that broke your site was made by someone else, on a schedule you did not choose. That is an argument for staging, not for pinning versions forever.

Reducing how often this happens

Four things, in rough order of how much they help:

1. Test updates on a staging copy. This catches nearly all of the above before a visitor sees it. It is the single highest-value change.
2. Make sure the admin email works. The recovery-mode email is genuinely useful and it is worthless if it does not arrive. Send yourself a test.
3. Keep a rollback path you have used. Not a backup you have never restored — a rollback you have actually performed once, so you know it works and how long it takes.
4. Know your PHP version and when it changes. Most hosts announce PHP upgrades. That announcement is the warning for an entire class of these failures.

The pattern across all four: this error is rarely preventable, because the code that breaks is usually not yours. What is entirely within your control is how long the site stays down once it happens.

How this fits the rest of the stack

Nearly all the time lost to this error is spent getting the error text, not fixing the problem — the message is deliberately vague, the email often does not arrive, and the log needs enabling before it records anything. Managed WordPress on RunxBuild puts a file manager and a database browser in the dashboard, so enabling debug logging or renaming a plugin folder does not begin with finding SFTP credentials, and runtime logs sit next to the deploy that caused them. Plans start at $3 a month; the RunxBuild hosting calculator shows that alongside the database and bandwidth as separate line items.

Useful related references:

• Python Logging Levels: What DEBUG, INFO, WARNING, ERROR and CRITICAL Are Actually For
• The Transfer Has Triggered a Web Application Firewall: How to Unblock It
• link to domain: The Three Layers Every Custom Domain Has and the Order to Wire Them
• Services on RunxBuild

FAQ

How do I see the actual error behind this message?

Set WP_DEBUG and WP_DEBUG_LOG to true and WP_DEBUG_DISPLAY to false in wp-config.php, reload the site, then read wp-content/debug.log. The last entry names the file and line. Turn all three off when you are done.

Why did I not get the critical error email?

It is sent by PHP mail from your own domain, which is a profile spam filters treat harshly, and many hosts have no working outbound mail at all. Check spam first, then fall back to enabling the debug log.

What is WordPress recovery mode?

A link in the critical error email that logs you into wp-admin with the failing plugin or theme paused. It gets you into the dashboard on a site that is otherwise entirely inaccessible.

How do I deactivate plugins if I cannot log in?

Rename wp-content/plugins to wp-content/plugins-off with a file manager or SFTP. WordPress deactivates all of them. Rename it back, then reactivate one at a time to find which one is responsible.

Why does debug.log not get created?

The wp-content directory is not writable by the web server. Either fix the permissions, or set WP_DEBUG_LOG to an explicit path in a directory that is writable rather than to true.