A failed WordPress update leaves the site in one of three states: stuck in maintenance mode, throwing a fatal error, or quietly running a half-written mix of old and new files. Each state has a specific recovery, and the order matters, because the standard reflex of running the update again makes the third state worse. Here is how to recover from a failed WordPress update, and then how to find out why it failed.
First, work out which state you are in
Load the front page and /wp-admin and read what each one says. The wording tells you the state.
- “Briefly unavailable for scheduled maintenance. Check back in a minute.” State one. A lock file was left behind.
- “There has been a critical error on this website”, or a blank page. State two. Something is throwing a fatal error.
- Everything loads, but a feature is broken or the admin behaves oddly. State three, the silent half-update, and the most dangerous of the three.
- The updater is still spinning on the Updates screen. Not yet a failure. Give it a few minutes on a large update before deciding, then reload the page rather than clicking again.
Whatever the state, do not start the update again yet. Retrying a failed WordPress update over half-written files is how a recoverable incident turns into a restore.
State 1: stuck in maintenance mode
This is the friendliest version of a failed WordPress update. If every page says “Briefly unavailable for scheduled maintenance”, the update crashed midway and left its lock file behind.
WordPress creates a file called .maintenance in the site root at the start of an update and deletes it at the end. When the process dies in between, the file stays and every visitor sees the notice. Delete that file over SFTP or in your host’s File Manager and the site returns instantly. The leading dot means many file managers hide it, so switch on “show hidden files” if you cannot see it.
However, do not stop there. The update that crashed is still incomplete, so check which component was mid-flight and verify its files before you trust the site. A site that loads is not the same as a site that updated.
State 2: a fatal error after the update
WordPress may email the administrator a recovery link when this happens, with the subject “Your Site is Experiencing a Technical Issue”. That is the fastest way back in, so search the admin inbox first.
Otherwise, make the error visible by enabling debug logging and reading the last fatal entry, exactly as with any WordPress white screen. The log names the component. Deactivate or roll back that one component rather than everything.
Also keep the failed version’s files rather than deleting them. The difference between them and a fresh copy shows what actually went wrong, and it is the only evidence you will have if the same update fails again on the next attempt.
State 3: the silent half-update
The most dangerous outcome of a failed WordPress update shows no error at all. The updater copied some files and not others, so the site now runs a mixture of versions. Symptoms surface later: odd admin behaviour, one broken feature, or a fatal error the first time an unusual code path runs.
Consequently, after any update that reported an error, re-install that component cleanly from an official download rather than assuming the retry fixed it.
For a plugin, delete its folder and install a fresh copy of the version you want. Deleting the folder does not delete its settings, which live in the database, so this is safer than it sounds. For a theme, do the same, but check first that the theme keeps its settings in the database rather than in files.
For core, replace wp-admin and wp-includes with fresh copies from an official WordPress download of the same version. Also replace the loose PHP files in the site root. Two exceptions: leave wp-config.php alone, and never touch wp-content. Your themes, plugins and uploads all live there.
Check whether the database upgrade ran
A core update has two halves: the files, and a database routine that runs afterwards. A failed WordPress update can complete the first and skip the second.
Visit /wp-admin/upgrade.php directly. If the database needs updating, WordPress says so and offers a button. If it is already current, it tells you that too, and you have ruled the question out in ten seconds.
This one matters because a mismatch between new files and an old database schema produces symptoms that look like plugin conflicts, and people chase those for hours.
Rolling a plugin back safely
When the update itself is the fault, going back a version is a legitimate fix while you wait for a corrected release.
Plugins hosted on WordPress.org publish every previous version on their page under Advanced View, near the bottom. From there you can download a specific release as a zip. Note the version you were on before, because “the previous one” is not always the one you had.
Then delete the current copy and install the older zip. Afterwards, switch off automatic updates for that plugin until the problem release is superseded. Otherwise the site quietly updates itself back into the failed WordPress update overnight.
Also read the plugin’s changelog before rolling back. If the release you are reverting fixed a security issue, staying on the old version is a different risk that you should take deliberately rather than by accident.
Why a failed WordPress update happens
Most failures trace to one of five causes, and your hosting logs distinguish them.
- The server ran out of disk space. The update writes a zip, extracts it, and needs room for both. Check disk usage in the hosting panel first. This cause is invisible everywhere else.
- PHP timed out midway. Slow storage plus a large plugin equals a process killed in the middle of copying files. This produces state three more often than state two.
- File permissions blocked writes. The update half-succeeds, writing what it can. Frequently this appears after a site migration changed file ownership.
- Two updates ran at once. An automatic background update and a manual one can collide, and each assumes it owns the filesystem.
- WordPress asked for FTP credentials. When it cannot write directly, WordPress prompts for FTP details, and an update abandoned at that prompt looks exactly like a failure.
Read the logs before choosing a story. A failed WordPress update caused by a full disk and one caused by a permissions change need completely different fixes, and they look identical from the dashboard.
Stopping the next one
The structural fix is staging. Updates run first on a copy of the site, faults appear there, and production only receives changes that survived. Most managed hosts include a staging environment, and using it costs one extra click per update.
In addition, a restore point taken before every update turns the worst case into a ten-minute rollback instead of an emergency. If you can only have one of the two, take the restore point.
Then update in batches rather than all at once. Core first, then plugins in small groups, checking the site between groups. When something breaks, you know which group did it, which is most of the diagnosis for free.
Finally, watch what updates itself. Automatic updates are on by default for some components. A site that updates unattended at three in the morning is a site whose failures you hear about from customers rather than from a log.
Quick checklist
In short: identify the state from what the site says, delete the maintenance lock if present, then make any fatal error visible. Next, re-install the component that was mid-flight cleanly, check /wp-admin/upgrade.php, and read the hosting logs for the cause.
After a failed WordPress update, the retry is the last step and never the first, because retrying over half-written files compounds the damage you are trying to undo.
If the site is down right now
Recovery beats diagnosis when the site is offline and taking losses. That is what our emergency WordPress support is for. We bring the site back with the smallest safe change, then run the root-cause work so the same failed WordPress update cannot happen the same way twice.
Tell us what was updating when it broke, and include your host name. If the site came back but now drags, our guide to a WordPress site slow after an update covers that separately.
For routine protection, our maintenance plans stage every update and keep the restore point that makes failures boring. The official WordPress update documentation covers the manual re-install path referenced above, and the common WordPress errors reference lists the messages you may find in the log.