WordPress Recovery Mode Not Initialized? Fix the Link and Email

You open the recovery link from WordPress’s “Your Site is Experiencing a Technical Issue” email and get a plain page with one sentence: Recovery Mode not initialized. The site still shows the critical error message, and every reload of the dashboard tells you to check your inbox again.

This guide explains what the message means in WordPress’s own code, why recovery emails often stop arriving after the first one, and the safe ways back into the dashboard. Every behavior described here was checked against the WordPress 7.1.4 source and reproduced on a disposable WordPress 7.1.4 test site. The test method and its limits are at the end.

What “Recovery Mode not initialized” means

When a plugin or theme causes a fatal PHP error, WordPress can email a private sign-in link. The link points to your login page with two values attached: rm_token, which identifies a stored record, and rm_key, a secret that must match it. WordPress keeps each record in an option called recovery_keys, together with a hashed copy of the key and the time it was created.

https://example.com/wp-login.php?action=enter_recovery_mode&rm_token=TOKEN&rm_key=KEY

action=enter_recovery_mode   asks WordPress to start a recovery session
rm_token=TOKEN               looks up one stored record (22 characters)
rm_key=KEY                   must match that record's hashed key (22 characters)

The key-checking code in WordPress 7.1.4 runs in a fixed order. If no record exists for the token, it stops immediately. If a record does exist, WordPress deletes it first and only then checks the record’s format, the key and its age. The code’s own comment is blunt: recovery keys can only be used once, and the key is consumed in the process. Each outcome shows a different sentence:

• Recovery Mode not initialized. No record exists for this token. The link was already used, was removed after it expired, or was created by a different copy of the site.
• Recovery key expired. The record existed but was older than the link lifetime. It has now been deleted.
• Invalid recovery key. The token matched but the key did not, usually because the address was altered. The record has now been deleted, so the original link will not work either.
• Invalid recovery key format. The stored record was damaged. It has been deleted.
• Recovery Mode Initialized. Please log in to continue. The link worked and your browser now holds a recovery session. If the dashboard still crashes after you log in, either no session was really started, as with the shortcut described further down, or the error comes from code recovery mode cannot pause, such as a must-use plugin.

So the message does not mean recovery mode is switched off or damaged. It means the database that received your click holds no record for that token. Nothing you do with the same link will bring the record back. You need a new link, or a route into the site that does not depend on email.

Why a recovery link stops working

• It has already been used. The first request that presents a stored token removes it, whether that request succeeds or not. Tapping the link on your phone and then opening it again on your laptop, a double click, or a colleague opening a forwarded copy all count. In the WordPress 7.1.4 test, one deliberately wrong key produced Invalid recovery key, and the untouched correct link then failed with Recovery Mode not initialized.
• Something opened it before you did. Some email security services check links before you see the message. Supabase’s authentication email documentation warns that features such as Microsoft Defender Safe Links can prefetch links and consume single-use sign-in URLs. WordPress does not distinguish a scanner from a person: any request that presents the stored token uses it.
• It is old. By default a link is valid for one day, the same as the gap between recovery emails. Expired records are deleted by a daily cleanup task, after which an old link reports not initialized rather than expired.
• The database changed. If the site was restored from a backup taken before the email, migrated, or the email came from a staging or cloned copy, the database receiving the click never held that record.
• The address was cut or altered. A link wrapped across two lines, copied without its end, or rewritten by a mail system can carry a token WordPress has never seen.

1. Stop reusing old links and read the email

Close the tab that shows the message and do not refresh it. Every extra attempt with a link that still has a stored record spends it, and WordPress will not send a replacement on demand. Then find the newest recovery email rather than an older one in the same thread.

1. 1Search the mailbox for the subject Your Site is Experiencing a Technical Issue. WordPress puts the site name in square brackets in front of it.
2. 2Note when the newest one arrived. With default settings, a link older than one day will not work.
3. 3Read the line that begins In this case, WordPress caught an error with. It names the plugin or theme WordPress traced the crash to.
4. 4Copy the Error Details section into a private note: error type, line, file path and message. The path shows the folder involved, for example wp-content/plugins/example-plugin/.
5. 5Note the WordPress, theme, plugin and PHP versions listed further down the email.

Do not forward the email to someone just to check the link. Whoever opens it first gets the one recovery session in their own browser, and the error details reveal file paths on your server. If a developer is helping, send the cause line and error details from your note instead of the link.

2. Work out whether WordPress will send a new email

A new link only arrives when WordPress decides to send one. The conditions are stricter than most tutorials suggest, and the error page does not tell you which one blocked the email.

• The crash must happen on a protected request. In WordPress 7.1.4, protected requests are the login page, the admin area and a short list of admin actions such as plugin installs and updates. A crash that only appears on public pages sends nothing. In the test, the same broken plugin produced no email from the home page and one email as soon as /wp-admin/ was opened.
• One email per day by default. WordPress records the time of each attempt in the recovery_mode_email_last_sent option and waits one day, the recovery_mode_email_rate_limit default, before trying again. Reloading the dashboard during that window sends nothing.
• A failed send still starts the wait. The email code stores the attempt time before it calls the mailer. If the server cannot send, there is no retry until the day has passed. A simulated failed send in the test was followed by a crash that made no new attempt.
• Only plugins and themes qualify. WordPress looks at the file where PHP reports the fatal error and only acts when it is inside the regular plugins folder or a theme folder. Errors reported in must-use plugins, drop-ins such as object-cache.php, wp-config.php or WordPress core files produce no recovery email, even when a plugin triggered them.
• Multisite networks are excluded. The loading sequence in wp-settings.php only starts recovery mode on single sites, so a network shows the critical error without a recovery email. The same file loads must-use plugins before recovery mode starts.
• The feature can be turned off. A WP_DISABLE_FATAL_ERROR_HANDLER constant set to true, or the matching filter, disables it entirely. The handler also stays out of the way while an update is still running, a state covered in the maintenance-mode guide.

If the day has passed and the crash still affects the dashboard, loading /wp-admin/ once is enough to trigger a new email. If you cannot wait, someone with SSH and WP-CLI access can clear the wait with WP-CLI’s option delete command:

# Clears only the "last sent" time. Plugins and themes are skipped so the
# broken code does not load while the command runs.
wp option delete recovery_mode_email_last_sent --skip-plugins --skip-themes

Then open /wp-admin/ once. In the test, deleting that option let the next dashboard request make a new email attempt. Anyone with that level of access can also deactivate the failing plugin directly, which is often faster than waiting for mail; the manual route is below. Exiting recovery mode clears the same wait automatically.

3. Check where the recovery email goes

WordPress sends the link to exactly one destination. If RECOVERY_MODE_EMAIL is defined in wp-config.php with a valid address, that address receives it. Otherwise it goes to the Administration Email Address under Settings → General. The constant replaces the general address rather than adding to it: in the test, with both set, the email was addressed only to the constant’s mailbox.

Search that mailbox, its spam folder and any quarantine your organization uses for the subject line. Business filters sometimes hold messages sent by a website’s own server until an administrator releases them.

The sending route matters too. WordPress loads regular plugins in a fixed order, which it sorts alphabetically by plugin folder whenever a plugin is activated. If the failing plugin loads before your SMTP or mail-delivery plugin, the mail plugin never runs, and the recovery email leaves through the server’s default mail setup. The official Recovery Mode documentation notes that such mail may be filtered as spam or blocked. When a theme fails, every plugin has already loaded, so your normal mail route is more likely to be used. The contact form email guide explains how to test what the server itself can deliver.

To send recovery links to a monitored team address, add the constant above the comment that tells you to stop editing:

// wp-config.php: add above the "That's all, stop editing!" comment
define( 'RECOVERY_MODE_EMAIL', 'site-alerts@example.com' );

Use an address on your own domain that more than one person can read, as covered in the business email guide. Changing the address does not bring back a link that was already sent elsewhere.

4. Open one fresh link in the browser you will use

A valid link does not log you in. The link handler places a recovery cookie, named wordpress_rec_ followed by a site-specific hash, in the browser that opened it, then sends you to the login page with the message Recovery Mode Initialized. Please log in to continue. You still need a working administrator username and password.

1. 1Open the email on the computer where you will fix the site. If it arrived on your phone, open the same message on that computer instead of tapping the link on the phone first.
2. 2Click the link once, or paste the complete address into the address bar if your mail program breaks it across lines. If you use a private window, keep it open until you finish, because closing it discards the session.
3. 3Log in normally. If the crash also affects the login page, WordPress pauses the failing plugin for your session and reloads the page once.
4. 4Stay logged in until you have finished. Logging out ends recovery mode in that browser.

The session belongs to the browser, not to your account. According to the cookie code, it lasts up to a week by default, and the Exit Recovery Mode button in the toolbar ends it at any time. If login itself fails after the message appears, follow the WordPress login recovery guide. Recovery mode does not bypass a wrong password, a two-factor prompt or a blocked login page.

5. Fix or deactivate the paused plugin or theme

After you log in, the dashboard shows a notice that begins One or more plugins failed to load properly, or the same notice for themes, with a link to the details. On the Plugins screen, the Paused view lists each plugin WordPress has paused, with the note This plugin failed to load properly and is paused during recovery mode, followed by the recorded error.

Paused is not the same as deactivated. The plugin is still active for everyone else; WordPress only skips it for your recovery session. In the test, the public home page kept returning the critical error while the recovery session used the dashboard normally. Choose one of these:

• Deactivate it. This is the immediate fix for visitors when the paused plugin is the only failure, and its settings normally stay in place for later.
• Update or replace it, then resume. Install a fixed version and click Resume. The resume code test-loads the plugin first; if it still crashes, you see Plugin could not be resumed because it triggered a fatal error, and it stays paused.
• Switch themes. If the email blamed your theme, activate a default theme under Appearance → Themes, then fix or update the original on a staging copy.

Avoid deleting a plugin from the dashboard as a first move. Deleting it there runs its uninstall routine, which can remove its settings and data. If several plugins fail, recovery mode pauses each one as it is reached, so check the full Paused list rather than only the first name.

When you are done, click Exit Recovery Mode. WordPress removes the recovery cookie, clears the paused list for that session and resets the email wait, and every extension runs normally again. Test the public site in a private window: if the critical error remains, the cause has not been removed.

No working link? Deactivate the plugin directly

If no usable email arrives, recovery mode is optional. The WordPress documentation itself points to file access as the fallback, and the error path from the email tells you which folder to change. Take a backup of the files and the database first, and change only the named plugin.

With SSH access and WP-CLI, skip plugins and themes so the broken code does not load while each command runs. Must-use plugins still load, so this route will not get around an error inside one of them.

# Confirm the folder name of the plugin named in the email
wp plugin list --status=active --skip-plugins --skip-themes

# Deactivate only that plugin (example-plugin is a placeholder)
wp plugin deactivate example-plugin --skip-plugins --skip-themes

# If the email named the active theme, switch to an installed default theme
wp theme activate twentytwentyfive --skip-plugins --skip-themes

Without SSH, use the host’s file manager or SFTP. Rename only the folder from the error path, for example wp-content/plugins/example-plugin to example-plugin-disabled. WordPress no longer finds the plugin file, so it stops loading it, and the next visit to the Plugins screen deactivates it with the reason Plugin file does not exist. Install a fixed version before activating it again; renaming the old folder back restores the same broken code.

Shortcuts that waste time

Several popular tutorials repeat shortcuts that do not match how WordPress works. These are the ones checked in the source and the test:

• Adding ?action=entered_recovery_mode to the login address. In the login page code, that parameter only chooses which message to display. It sets no recovery cookie and pauses nothing. When the test plugin crashed every request, the address returned the same critical error. When it crashed only the admin area, the login page showed “Recovery Mode Initialized”, but after logging in the dashboard still failed.
• Expecting RECOVERY_MODE_EMAIL to add a second recipient. It replaces the administration address for recovery emails.
• Refreshing to request another email. The page text stays the same, but no new email is sent until the wait ends or is cleared.
• Treating recovery mode as the fix. It only pauses code for one browser. Visitors keep seeing the error until the plugin or theme is deactivated, replaced or repaired.

Prevent the next lockout

1. 1Point recovery mail at a monitored team mailbox with RECOVERY_MODE_EMAIL, and check that the Administration Email Address under Settings → General is current.
2. 2Make sure the server can deliver mail on its own, or ask your developer to configure delivery in a must-use plugin or at server level. Must-use plugins load before regular plugins, so their mail settings are already in place when a regular plugin crashes.
3. 3Record who holds the hosting panel, SFTP and WP-CLI access, using the website handover checklist. A recovery email is a convenience; file access is the dependable route.
4. 4Update plugins one at a time, and test major updates on a staging copy before they reach the live site.
5. 5Ask everyone who shares the admin mailbox not to open recovery links to see whether they work.

When to hand it to a developer

Stop and get help if the error names a must-use plugin, a drop-in, wp-config.php or a WordPress core file; if the site is part of a multisite network; if nobody has hosting or file access; or if a store is losing orders while you wait for email. Those cases need someone working from the server rather than the dashboard.

Send the exact message you saw, the time, the plugin or theme named in the email and the Error Details lines from your note. Do not send the recovery link, passwords or database credentials; a temporary hosting invitation can be arranged instead. My WordPress development and repair service and website maintenance plans cover this kind of recovery, and you can send the details here.

Frequently asked questions

Can I enter WordPress recovery mode without the email?

Not through a web address. WordPress only starts a recovery session from a link whose token is stored in its database. Without one, deactivate the failing plugin with WP-CLI or by renaming its folder, or wait for the next email. Developers can force a session with the WP_RECOVERY_MODE_SESSION_ID constant in a must-use plugin, but the WordPress 5.2 developer note warns that setting it unconditionally enables recovery mode globally.

How long does a WordPress recovery link last?

One day by default, and it works once. The recovery_mode_email_link_ttl filter can lengthen it, but WordPress never makes it shorter than the gap between recovery emails. After a link has been used, the recovery session in that browser lasts up to a week unless you log out or exit recovery mode.

Why does WordPress say to check my inbox when no email arrived?

The sentence appears on the dashboard and login page whenever recovery mode is available, not only when an email was sent. An earlier email within the last day, a failed send or a fatal error reported in a WordPress core file can all leave the same message on screen.

Does recovery mode work on WordPress multisite?

No. WordPress only starts recovery mode on single-site installations, so a network shows the critical error without a recovery link. Use network admin access, WP-CLI with its --network option for network-activated plugins, or the host’s file access instead.

Is it safe to forward the recovery email?

Avoid it. The link works once, so whoever opens it first, including an automated link checker, uses it up. The email also contains file paths from your server. Share the cause line and error details instead, and let the person doing the repair use their own access.

What does Exit Recovery Mode do?

It removes the recovery cookie from your browser, clears the list of paused extensions for that session and resets the one-email-per-day wait. Every plugin and theme then loads normally. If the failing code is still active, the critical error comes back for you as well as for visitors.

Sources, test and review scope

The behavior described here comes from the WordPress 7.1.4 source at commit 0afb74de, mainly the recovery mode controller and the key, link, cookie and email services linked above, together with the fatal error handler, the loading sequence and the admin plugin functions. Background comes from the WordPress.org Recovery Mode documentation and the 5.2 developer note.

The behavior was then reproduced on a disposable WordPress 7.1.4 site running in WordPress Playground with PHP 8.5.12 and SQLite. A test plugin called an undefined function to cause a fatal error, and a test must-use plugin recorded outgoing emails instead of sending them. Across 22 recorded steps and 32 checks, the results matched the source:

1. 1A crash on the public home page returned the critical error and sent no recovery email.
2. 2The same crash on /wp-admin/ made one email attempt, addressed only to RECOVERY_MODE_EMAIL.
3. 3Repeat dashboard requests kept showing the inbox message without another email.
4. 4The first request to the link set the recovery cookie and removed the stored key; a second browser then got Recovery Mode not initialized.
5. 5A wrong key produced Invalid recovery key, and the correct link failed afterwards.
6. 6A simulated failed send still started the one-day wait.
7. 7The entered_recovery_mode login address never started a recovery session.

Limits: one single-site installation on a test runtime. The test did not cover multisite, real mail delivery, email security scanners, hosting firewalls, other WordPress versions or a client’s website. Prepared on 7 November 2026 with AI-assisted research and editing. The photographs are licensed contextual stock images, not screenshots of a WordPress incident.