Your site shows a critical error. The message on the screen says an email has been sent to the site administrator with instructions. You check your inbox. Nothing. You check it again five minutes later. Still nothing.
This is a common and badly served situation, because almost every guide treats the recovery email as the reliable route and stops there. It is not always reliable, and the reason it fails is often the same reason the site broke.
Why it fails, so you know how long to wait
Recovery Mode works like this: WordPress detects a fatal error in a plugin or theme, pauses the offending extension, and emails a special login link to the site's administration address. Following that link logs you into an admin where the broken extension is switched off, so you can fix or remove it.
Every part of that chain can break.
Your site may not be able to send mail at all. WordPress hands mail to the server, and a large number of hosts either do not send it, have it blocked, or route it somewhere that gets it filtered. This is a normal, pre-existing condition on many sites and most owners never discover it, because they never needed a system email until the day they did.
The email goes to the administration address, not to your user account. These are two different settings, and on sites built by someone else they are frequently different. The administration email lives in the general settings, and it may be the developer's address, an old address, or a mailbox nobody reads.
It may have arrived and been filtered. Check spam, promotions, and any rule you have set up. The message comes from your own site, which is exactly the profile spam filters distrust.
The error may not be the kind that triggers it. Recovery Mode is for fatal PHP errors in plugins and themes. A database connection failure, a server error, or a broken core file does not produce a recovery email, and waiting for one in those cases is waiting for something that was never sent.
Give it five minutes, then stop waiting. There is also a rate limit by design, so repeatedly reloading the broken page will not generate a new email each time.
Door one: your host's webmail or mail log
Before assuming the email was never sent, check whether it was sent and simply not delivered to where you are looking.
If the administration address is on your own domain, your host almost certainly provides webmail. Log into the hosting control panel and read that mailbox directly. It is common to find the message sitting there because the address forwards to a mailbox that no longer exists.
Many hosts also expose a mail delivery log. If the message shows as sent and bounced, you have learned something useful about the site beyond today's problem.
Door two: change the administration email from the database, or ask your host
If the administration address is wrong, changing it fixes the route permanently rather than just today.
You cannot change it from the admin if you cannot reach the admin. There are two realistic ways in for a non-developer.
Ask your host's support. Most managed and shared hosts will do this or point you at the tool that does. This is a legitimate use of the support you pay for, and it is far safer than editing a database table you do not know.
Use the database tool in your control panel. The value lives in the options table as admin_email. This is an accurate description of where the setting is, not a recommendation to go and edit it. Editing a database table by hand on a site that is already broken is a way to have two problems, and unless you are comfortable with what you are doing, door three is a better use of the next ten minutes.
Door three: disable the offending extension yourself
This is usually the fastest real fix and it does not depend on email at all.
Recovery Mode's entire value is that it pauses the broken plugin so you can get in. You can achieve the same result directly by disabling plugins at the file level, using your host's File Manager or an FTP client. Renaming the plugins folder switches all plugins off at once, and renaming a single plugin's own folder switches off just that one, which is the surgical version if the error message named a file path.
This is the standard route for a locked-out site and it is covered in full in our guide to disabling plugins without access to wp-admin. If the error appeared immediately after an update, our critical error after an update walkthrough sets out the order in which to work.
If the culprit is the theme rather than a plugin, renaming the active theme's folder makes WordPress fall back to a default theme, if one is installed. If no default theme is present, this makes things worse rather than better, so check before you rename.
Door four: the debug log, read from outside
You do not need to be logged in to read the debug log. If debugging was already on, the log is sitting in wp-content and you can download it. It will usually name the file where PHP stopped, which tells you which plugin folder to rename in door three.
If debugging was not on, you can turn it on by editing wp-config.php over FTP, then reload the broken page once and read the result. That is a real and reasonable option even with the site down, and it converts guesswork into a name.
What not to do
Do not reinstall WordPress to fix a plugin error. It is a large action with real risk and it does not address the cause.
Do not delete plugins to get the site back. Rename or deactivate them. Deleting can remove their data too, and you may want that data once the site is up.
Do not follow a database instruction you do not understand. Search results for lockout problems reach SQL commands quickly, and running one you cannot read on a live database is how a recoverable outage becomes an unrecoverable one.
Afterwards: make the email work
Once the site is back, fix the underlying failure, because it will matter again. Confirm the administration address is a mailbox you actually read. Send yourself a test email from the site, for instance by triggering a password reset, and confirm it arrives. If it does not, your site cannot send mail, and that affects password resets, order confirmations and contact forms as much as it affects recovery links.
That is a quiet, invisible fault on a great many WordPress sites, and the day of an outage is a bad day to discover it.
Version context. Written against WordPress 7.1, released 2026-08-19, the current major release on our record. Recovery Mode has been core behavior since WordPress 5.2 and is not a 7.x feature. Release dates come from our own dated record of the WordPress.org release page, last read 2026-08-19.
