How to Fix a Failed WordPress Update (Including Stuck Maintenance Mode)

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.

A failed WordPress update is usually recoverable without rebuilding the site. First make a restorable copy of the database and files. Then match the symptom to the least destructive fix: remove a stale .maintenance file when the site is locked in maintenance mode, correct connectivity or permissions for a dashboard download failure, use the official manual-update sequence when files were only partly replaced, and use Recovery Mode when a plugin or theme causes a fatal error. If server limits or PHP compatibility are involved, restore a known-good backup or involve your host before making changes you cannot reverse.

Start with a backup you can actually restore

Do not retry an update while your only copy of the site is the damaged installation. WordPress’s update guidance recommends a backup before updating, and automatic plugin and theme updates are safe to enable only when a rollback is available. Create both parts of the site backup:

#	Preview	Product	Price
1		WordPress Multisite Administration	$34.38	Buy on Amazon
2		Mon Site WordPress – Volume 2 – Administration & Utilisation (French Edition)	$9.90	Buy on Amazon
3		WordPress 24-Hour Trainer	$3.95	Buy on Amazon
4		Teacher Record Book	$4.89	Buy on Amazon

• Database: Export every WordPress table, including posts, pages, users, settings, and plugin data. Keep the export outside the web root.
• Files: Copy the entire WordPress installation, including wp-content, uploaded media, themes, plugins, configuration, and the core files currently on the server.

Label the backup with the date and the WordPress version shown on the dashboard or in the site files. A backup is not a recovery plan until you know it is readable: open the database export, confirm the file archive contains wp-config.php and wp-content, and, when practical, test restoration on a staging installation. If your host supplies snapshots, verify how to restore both the database and files rather than assuming a file snapshot includes the database.

Do not overwrite the backup while experimenting. Keep the original copy untouched so you can return to the pre-update state if a second attempt makes the failure worse.

#1 Best Overall

Sale

WordPress Multisite Administration

$34.38

Buy on Amazon

Match the symptom to the safest recovery path

The visible message and the access you still have determine what to do next. This table separates a marker cleanup from operations that replace files or change the database.

Remove a stale maintenance file

During an update WordPress places a hidden file named .maintenance in the WordPress root. It normally removes that file when the operation finishes. If the process is interrupted, the marker remains and every visitor can receive “Briefly unavailable for scheduled maintenance. Please check back in a minute.” Removing the marker clears the lock; it does not fix a failed download, bad permissions, incompatible PHP, or a broken plugin.

Using FTP or a hosting file manager

1. Open the FTP client or your host’s file manager and enter the directory containing wp-admin, wp-includes, and wp-content.
2. Enable display of hidden files. Files beginning with a dot may be hidden by default.
3. Confirm that the file is exactly .maintenance in the WordPress root, not a similarly named file inside wp-content.
4. Delete only .maintenance. Do not remove wp-config.php, .htaccess, or an entire directory.
5. Load the public site and /wp-admin in a private browser window. If they open, review the dashboard for an incomplete-update notice before retrying.

Using shell access

Change to the WordPress root, verify the path with a directory listing, and remove the marker:

cd /path/to/wordpress
ls -la .maintenance
rm .maintenance

Use the absolute path supplied by your host instead of the example path. If ls reports that the file does not exist, do not create or delete a replacement; investigate the actual error shown by the site. A recurring maintenance message means the underlying update is still failing, so continue with the dashboard, manual-update, or server diagnosis rather than repeatedly deleting the marker.

Diagnose a failed dashboard update

When the package will not download

A download failure can result from a temporary connection problem or a server that cannot reach the update service. Wait briefly, confirm that the server has outbound network access, and retry once. If the same error returns, ask the host whether firewall rules, DNS, a proxy, or an outbound HTTP restriction is blocking the request. Your browser’s internet connection does not prove that the web-server process can make the connection.

Rank #2

Mon Site WordPress – Volume 2 – Administration & Utilisation (French Edition)

$9.90

Buy on Amazon

When WordPress repeatedly asks for connection information

Repeated FTP or connection prompts usually indicate that the process running PHP cannot write the WordPress directory. Check the owner and group assigned to the files and directories, then check that the web server has the required write access for the update. Do not broadly set every file to world-writable: that creates a security problem and may conceal the real ownership error. A host can correct ownership and apply a least-privilege permission scheme without exposing the site.

After correcting the server condition

1. Confirm that the site loads and that the maintenance marker is absent.
2. Take a fresh backup if the failed attempt changed files or database content.
3. Run the update from Dashboard → Updates only once the host confirms connectivity and write access.
4. Watch the complete process, including any database-upgrade prompt, rather than closing the browser as soon as the download starts.

If the dashboard still fails after connectivity and ownership are verified, stop repeating one-click attempts and use the manual procedure below.

Complete the official manual update

Manual updating replaces the distributed WordPress core when the automatic method cannot finish. Download the exact WordPress release you intend to run from the official WordPress distribution, and keep your backup available before touching production files. The procedure below assumes you can use FTP, a file manager, or shell access.

1. Put the site in a controlled state. Announce a brief maintenance window if the site receives traffic. Deactivate plugins from Plugins → Installed Plugins when the dashboard is available. If the dashboard is inaccessible, do not guess at database edits; use the documented file-based recovery or ask your host.
2. Unpack the matching release away from the live directory. Keep the new package separate so you can compare it with the existing installation before copying anything.
3. Preserve site-specific content. Do not replace wp-content unless a separate, deliberate plugin or theme repair requires it. Keep wp-config.php and your server configuration. Customizations made directly to distributed core files will be lost because those files are replaced; move custom behavior into a plugin or child theme instead.
4. Replace the core directories. Replace wp-admin and wp-includes with the directories from the release package. Do not merge an unknown mixture of old and new core files.
5. Replace the distributed root files. Copy the release’s root PHP files and other distributed files over the existing versions, while retaining your site’s wp-config.php and any host-specific files that are not part of the WordPress package.
6. Remove a leftover marker. If the failed automatic attempt left .maintenance in the root, delete it using the FTP, file-manager, or shell method described earlier.
7. Run the administrator check. Visit /wp-admin. WordPress may redirect you to upgrade.php and display a database-upgrade request. Complete it immediately; do not dismiss the prompt and start activating extensions on an unmatched schema.
8. Re-enable extensions carefully. Reactivate plugins one at a time and check the public site and dashboard after each activation. Leave the component disabled if it triggers a fatal error.

The manual path changes core files, so retain the pre-update backup until the site has passed testing. A copied core file that contains a local edit is not a durable customization; future updates will overwrite it again.

Recover from a fatal error or white screen

WordPress Recovery Mode was introduced in version 5.2. When WordPress detects a fatal PHP error during a normal page load, it can email the administrator a special link. Recovery Mode pauses the suspected plugin or theme for that administrator session, allowing the dashboard to load far enough to identify the component without immediately editing code or using FTP.

Rank #3

Sale

WordPress 24-Hour Trainer

$3.95

Buy on Amazon

Use the Recovery Mode link

1. Open the recovery email sent to the site administrator and follow its time-limited link.
2. Authenticate with an administrator account if prompted.
3. Read the dashboard notice identifying the plugin, theme, or PHP file associated with the fatal error.
4. Deactivate, update, or replace the named component. If it is a theme, switch temporarily to a default theme while you investigate.
5. Exit Recovery Mode, open a normal private-browser session, and test both the public site and the dashboard.

Pausing a component in Recovery Mode is not the same as repairing it. Check whether the component supports the WordPress and PHP versions now running, install a compatible release, or contact its developer. Keep the component disabled if reactivation immediately recreates the fatal error.

If no Recovery Mode email arrives

Check the administrator address and spam quarantine, but do not wait indefinitely while the site is down. Use the documented FTP or file-manager method to isolate the problem: rename the suspected plugin directory so WordPress cannot load it, or switch the active theme through the available recovery method. Make one change at a time and record the original name so you can restore it. Enable WordPress debugging only with a plan for protecting logs from public access, and involve the host when the error occurs before WordPress can load or points to a server extension.

Check server limits and PHP compatibility

Some update failures are outside the dashboard. The conditions below commonly require a hosting provider or a developer with server access:

• File ownership and permissions: The PHP process must be able to read the installation and write the locations required during an update. Correct the owner and group rather than applying permissive modes to everything.
• Memory limit: A plugin, theme, or database upgrade can exceed the PHP memory available to the request. The host must confirm the effective limit, which may differ between the dashboard, web requests, and command-line PHP.
• Maximum execution time: A large package, slow disk, or database migration can exceed the request timeout. Increasing a limit without checking the server’s hard cap may have no effect.
• PHP version and extensions: A newly updated WordPress core, plugin, or theme may require a PHP version or extension that is missing or incompatible. Match the supported combination before changing PHP on production.
• Connectivity: DNS, firewall, TLS, proxy, or outbound-request rules can prevent downloads even when visitors can reach the site.

Give the host the exact error text, approximate time, WordPress version, PHP version, and the last action performed. Do not ask the host to “fix permissions” without preserving the backup and noting the current owner and group; an indiscriminate change can break other applications on the same account.

Restore the site when the update cannot be repaired safely

Restoration is appropriate when the public site is down, the database upgrade is incomplete, or the cause cannot be isolated quickly. Restore the files and database from the same known-good point whenever possible. Mixing a newer database with older files, or older database content with newer files, can create a second incompatibility.

Rank #4

Teacher Record Book

• Keep track of everything from attendance to test scores
• Spiral bound
• Measures 8-1/2" x 11"

$4.89

Buy on Amazon

1. Place the site in maintenance mode at the host level if visitors could submit orders, comments, or other data during the rollback.
2. Record any transactions or content changes made after the backup; a restore can remove them.
3. Restore the complete file backup, including wp-content and configuration, and import the matching database backup.
4. Clear a stale .maintenance marker if the restored copy contains one.
5. Check the PHP version used by the backup. If PHP was changed after the backup was made, the host may need to return to the previous PHP version before the restored site will run.
6. Test the homepage, representative posts, login, media, forms, scheduled tasks, and the dashboard before reopening traffic.

If you cannot access the database, change PHP safely, or verify that the restore completed, stop and involve the hosting provider or a qualified developer. Repeated production experiments without a verified rollback increase the chance of losing both the current site and the recovery copy.

Verify the repair before declaring success

• The public homepage and several internal URLs return normally, with no maintenance or fatal-error message.
• /wp-admin opens for an administrator and does not repeatedly request connection credentials.
• Dashboard → Updates shows the intended WordPress version and no pending database-upgrade prompt.
• The database upgrade, if requested through upgrade.php, completed without an error.
• Plugins and the active theme are compatible and were reactivated deliberately, not all at once.
• Uploads, forms, authentication, scheduled jobs, caching, and email still work.
• Server logs no longer show permission denials, memory exhaustion, timeouts, or fatal PHP errors.
• The backup made before the retry remains stored separately and is still readable.

Keep the site under observation through normal traffic and scheduled tasks. A front page that loads once does not prove that background requests, administrator screens, or a plugin’s write operation are healthy.

Prevent the next failed update

Use scheduled WordPress backups that include both files and the database, and periodically verify a restore rather than merely checking that a backup job reports success. Test major core, plugin, and theme changes on a staging copy when your host provides one. Keep custom code in plugins or a child theme so a core replacement cannot erase it. Before enabling automatic plugin or theme updates, confirm that your backup system can roll back the exact installation and that someone will see an alert when an update fails.

WordPress.org’s update guidance is direct: “You should always update WordPress to the latest version.” Apply that advice with a controlled process—backup, compatibility check, update, database migration when requested, and post-update verification—so keeping current does not become an avoidable outage.

Quick Recap

SaleBestseller No. 1

WordPress Multisite Administration

$34.38

Bestseller No. 2

Mon Site WordPress – Volume 2 – Administration & Utilisation (French Edition)

$9.90

SaleBestseller No. 3

WordPress 24-Hour Trainer

$3.95

Bestseller No. 4

Teacher Record Book

Keep track of everything from attendance to test scores; Spiral bound; Measures 8-1/2" x 11"

$4.89

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.