WordPress Recovery Mode: What Triggers It, What It Means, and How to Respond

The safety net that does not catch you

WordPress 5.2 introduced recovery mode as the answer to a long-standing problem: when a plugin or theme update causes a PHP fatal error, the entire site goes down, and the site owner has no way to fix it without FTP access. Recovery mode was meant to solve this by catching the fatal error, pausing the offending code, and emailing the admin a special link to log in and deactivate the problem plugin.

The idea is sound. The execution has a critical flaw.

Recovery mode depends on WordPress being able to send an email. On shared hosting — where the vast majority of WordPress sites live — server mail is unreliable at best and completely broken at worst. The PHP mail() function fails silently. The email goes to spam. The hosting IP is on a blacklist. The admin email address is outdated. Any one of these failures means the recovery email never reaches you.

And while you are waiting for an email that will never arrive, your visitors are seeing a broken website. Every single one of them.

What triggers WordPress recovery mode

Recovery mode activates when WordPress's built-in fatal error handler catches a PHP error that prevents the page from rendering. This handler was added in WordPress 5.2 and lives in wp-includes/class-wp-fatal-error-handler.php. Here are the situations that trigger it.

1. A plugin update introduces a fatal PHP error

This is the most common trigger. You update a plugin — or WordPress auto-updates it in the background — and the new version contains code that crashes PHP. It might call a function that does not exist in your PHP version. It might have a syntax error. It might conflict with another plugin.

WordPress catches the crash, identifies the plugin, and activates recovery mode. If the mail system works, you receive an email identifying the plugin and containing a temporary login link. If it does not work, you receive nothing.

2. A theme update breaks functions.php

Your theme's functions.php file executes on every page load. A theme update that introduces incompatible code, a syntax error, or a conflict with your PHP version triggers a fatal error. Recovery mode activates and pauses the theme, falling back to a default theme for the admin session.

3. PHP version change on the server

Your hosting provider upgrades PHP from 8.1 to 8.3. A plugin or theme on your site uses a function that was deprecated or removed in the new version. The next time someone visits your site, PHP throws a fatal error. You did not change anything — the server changed underneath you.

Recovery mode catches this, but because the error affects the first page load after the PHP change, visitors are the ones who trigger it. They see the error. You see nothing until the email arrives — if it ever does.

4. Memory exhaustion during page load

If a plugin or theme consumes more memory than PHP allows, the process crashes with a fatal "allowed memory size exhausted" error. Recovery mode activates if WordPress's error handler can catch the crash before PHP terminates entirely. However, severe memory exhaustion can kill the PHP process before the handler runs, in which case recovery mode does not activate at all.

5. Corrupted core files after a failed update

A WordPress core auto-update that fails mid-way can leave corrupted files. If the damage is to a file that loads before the error handler — like wp-settings.php or wp-config.php — recovery mode never triggers. The site simply crashes with a blank page or a raw PHP error, and no email is sent.

What visitors see vs what you see

This is the part most WordPress documentation glosses over. Recovery mode does not fix anything for your visitors. It is exclusively for the site admin.

What your visitors see: The same broken page. Depending on the error, this could be the "There has been a critical error on this website" message, the White Screen of Death, or a 500 Internal Server Error from the web server. Recovery mode does not display a maintenance page or a friendly message. Your visitors see the raw error.

What you see (if the email works):An email from WordPress with the subject line "Your Site Is Experiencing a Technical Issue." The email identifies the error, names the plugin or theme that caused it, and includes a special URL that lets you log into wp-admin with the offending code paused. From there, you can deactivate the plugin, switch themes, or roll back changes.

What you see (if the email does not work): Nothing. Absolutely nothing. Your site is down, your visitors see an error, and you have no notification. You discover the problem when a customer emails you, when you see a drop in analytics, or when you happen to visit your own site. This could be hours, days, or even weeks later.

Why the recovery email is unreliable

The recovery email is the single point of failure in the entire recovery mode system. If the email does not arrive, recovery mode is useless. And there are many reasons it does not arrive.

Server mail is not configured

WordPress uses the PHP mail() function by default. Many shared hosting providers disable it, throttle it, or have it misconfigured. The function returns true (meaning it handed the message to the server) but the server never actually sends it. There is no error, no warning, no log entry. The email simply vanishes.

The hosting IP is blacklisted

Shared hosting servers send mail from an IP address shared by hundreds of other websites. If any of those websites have sent spam, the IP ends up on email blacklists. Your recovery email gets rejected by the receiving mail server before it ever reaches your inbox. You cannot control this — it depends entirely on what other tenants on your shared server are doing.

The email lands in spam

Even if the email is sent and accepted, it often triggers spam filters. WordPress sends a plain text email from a generic server address with a technical subject line. Email providers like Gmail, Outlook, and Yahoo filter these aggressively. The recovery link sits in your spam folder while your site stays broken.

Your SMTP plugin caused the crash

If you use a plugin like WP Mail SMTP, Fluent SMTP, or Post SMTP to handle email delivery — and that plugin is the one that caused the fatal error — WordPress cannot use it to send the recovery email. The plugin is the thing that crashed, so it cannot send the notification about its own crash. WordPress falls back to the default mail() function, which on most servers does not work.

The admin email is outdated

Recovery mode sends the email to the address stored in Settings > General > Administration Email Address. If this email is wrong, outdated, or belongs to someone who left the company, the recovery email reaches no one. On sites managed by agencies, the admin email might be a client's personal address that they never check.

Why you cannot rely on recovery mode alone

Recovery mode has too many failure points to be your only safety net. It depends on the error being caught by WordPress's handler (not all errors are). It depends on the mail system working (it often does not). It depends on you checking your email promptly (you might not). It depends on the email not being filtered as spam (it frequently is).

That is four independent points of failure, any one of which is enough to leave your site broken with no notification. You need monitoring that works from outside WordPress — something that does not depend on WordPress being functional to tell you it is not functional.

How to detect recovery mode errors with Uptrue

Uptrue's keyword monitoring checks your actual page content from outside your server. It does not depend on WordPress being able to send email. It does not depend on your hosting mail configuration. It checks what your visitors actually see and alerts you when the content changes.

Step 1: Set up a keyword monitor to detect the critical error text

1. Sign up at uptrue.io/signup (free plan available)
2. Click Add Monitor from your dashboard
3. Select Keyword as the monitor type
4. Enter your homepage URL
5. Set the keyword to "There has been a critical error"
6. Set the check type to "Page must NOT contain"
7. Set the check interval to 1 minute
8. Configure alerts — Slack, email, or Microsoft Teams

This catches the exact error that recovery mode is supposed to catch — except it works every time, regardless of whether WordPress can send email.

Step 2: Add a keyword monitor for recovery mode specific text

1. Click Add Monitor again
2. Select Keyword as the monitor type
3. Enter your homepage URL
4. Set the keyword to "technical issue"
5. Set the check type to "Page must NOT contain"
6. Set the interval to 1 minute

Some WordPress configurations display a slightly different message when recovery mode is active, including the phrase "experiencing a technical issue." This monitor catches that variant. Between this and the critical error monitor, you cover all the error messages WordPress shows during a fatal crash.

Step 3: Add a positive keyword monitor as a safety net

1. Add another Keyword monitor for your homepage
2. Set the keyword to your site title, tagline, or a navigation item that always appears
3. Set the check type to "Page must contain"
4. Set the interval to 1 minute

This catches any situation where your normal content disappears, whether it is replaced by an error message, a white screen, a hacked page, or anything else. If your expected content is missing, you know something is wrong — even if you do not know the exact cause yet.

Step 4: Monitor your critical inner pages

Fatal errors do not always affect every page. A plugin might only crash on pages where it is active — your contact form page, your WooCommerce checkout, your membership portal. Set up keyword monitors on:

• Homepage
• Contact page
• Checkout or cart page
• Any page with forms or dynamic functionality
• Landing pages receiving paid traffic

Step 5: Configure alerts that actually reach you

The whole problem with recovery mode is that its notification does not reach you. Do not repeat the same mistake with your monitoring alerts. Configure them to go where you will see them immediately:

• Slack — instant notification in a dedicated channel
• Microsoft Teams — same idea, different platform
• Email — use a reliable provider, not your WordPress server
• Webhook — pipe alerts into PagerDuty, Opsgenie, or your own system

Uptrue sends alerts from its own infrastructure — not from your WordPress server. When your server cannot send email, Uptrue still can. That is the fundamental difference between recovery mode and external monitoring.

What to do when recovery mode activates

If you do receive the recovery email — or if Uptrue alerts you and you suspect a fatal error — here is the fastest path to getting your site back online.

If you have the recovery link

Click the link in the WordPress recovery email. It logs you into wp-admin with the crashing plugin or theme paused. Deactivate the offending plugin. Check the WordPress troubleshooting FAQ for the specific error. Update or replace the plugin. Verify your site loads correctly.

If you do not have the recovery link

Connect via FTP or your hosting file manager. Navigate to /wp-content/plugins/ and rename the most recently updated plugin's folder to disable it. If you are not sure which plugin caused the crash, rename the entire plugins folder to plugins-disabled to deactivate all plugins at once. Load your site. If it recovers, rename the folder back and re-enable plugins one by one to find the culprit.

If the error is in the theme

Navigate to /wp-content/themes/ via FTP and rename your active theme folder. WordPress falls back to the latest default theme. If the site loads, your theme is the problem. Contact the theme developer or restore a backup of the theme files.

Stop finding out from your customers

WordPress recovery mode was designed with good intentions. But it depends on email, and email from WordPress servers is unreliable. Spam filters, blacklisted IPs, misconfigured mail functions, and outdated admin addresses all conspire to keep the recovery notification from reaching you.

External monitoring removes every one of those failure points. Uptrue checks your pages from outside your server, every 60 seconds. If your content disappears or an error message appears, you know in under a minute. Not when you happen to check your spam folder. Not when a customer complains. Not when your traffic drops and you finally investigate.

Under a minute. Every time. Regardless of whether WordPress can send a single email.

Frequently asked questions