How to fix "An automated WordPress update has failed to complete"

What does "An automated WordPress update has failed to complete" mean?

It means WordPress tried to update itself in the background, without anyone pressing a button, and the attempt did not finish. WordPress saves a record of the failure, and every administrator then sees this warning at the top of wp-admin: "An automated WordPress update has failed to complete - please attempt the update again now." Users who cannot update see a version asking them to notify the site administrator.

WordPress runs these background updates through WP-Cron, about twice a day, after it checks WordPress.org for new versions. By default it installs minor and security releases of WordPress itself automatically, major releases too where that is switched on, and plugin and theme updates where you have switched auto-updates on.

The warning is about WordPress core. Failed plugin and theme auto-updates come as an email instead, which we cover below.

Was it a minor failure or a critical one?

WordPress sorts a failed background update into two kinds, and they need different urgency. The difference is whether it had started copying files when it failed:

The version number in the table is an example; the email names the real one. Note the first subject line: it does not say anything failed. The body adds "An attempt was made, but your site could not be updated automatically", which is easy to miss.

The critical case is the one that matters. After a critical failure, the version file may already say the new version while other files are still old, which is why WordPress keeps the warning showing and refuses to try again on its own. Until a core update completes, this site gets no automatic security releases. Site Health says so in as many words under Background updates: "A previous automatic background update ended with a critical failure, so updates are now disabled."

Step 1: Is the site still working?

Open the home page, a couple of important pages and wp-admin, ideally in a private window so you see what visitors see.

• Everything loads. Good. Carry on to the next steps calmly.
• "Briefly unavailable for scheduled maintenance. Check back in a minute." WordPress shows this during an update, using a file called .maintenance in the site's main folder. WordPress ignores that file once it is ten minutes old, so the message usually clears on its own. If it stays, delete .maintenance with your hosting file manager or SFTP.
• "There has been a critical error on this website", or a blank page. Files may be half updated. Go straight to the manual update below, or restore your most recent backup. Our guide to the WordPress critical error helps you read the error log first.

Step 2: How do you run the update again?

Back up first, then go to Dashboard, then Updates, and press Update to version (or Re-install version). Running the update yourself from this screen is what WordPress asks for, and it is what clears the warning: when a core update finishes successfully, WordPress deletes its record of the failure.

If it works, you are done. Check the site once more. If it fails again, the screen now shows you the actual error, which the warning never did. The next section tells you what each one means.

What do the update error messages mean?

File ownership comes up again and again. WordPress writes its own files directly only when the user PHP runs as owns them. When it does not, WordPress falls back to asking for FTP details, which a background update cannot provide, so automatic updates silently fail on that server every time.

Step 3: How do you update WordPress by hand if the dashboard cannot?

With WP-CLI, three commands do it safely:

wp core update
wp core update-db
wp core verify-checksums

The first installs the latest version, the second runs any database changes the new version needs, and the third compares every core file with the copy on WordPress.org, which is the quickest way to be sure a half-finished update left nothing behind. A successful wp core update also clears the failure record, so the warning disappears.

Without WP-CLI, download the latest WordPress from WordPress.org and upload it over SFTP:

1. Back up the files and the database.
2. Replace the wp-admin and wp-includes folders completely.
3. Upload the loose files from the main folder of the download, overwriting the old ones.
4. Never overwrite wp-config.php or the wp-content folder: they hold your settings, themes, plugins and uploads.
5. Visit wp-admin. If WordPress asks to update the database, let it.

Why do automatic updates fail in the first place?

• File ownership and permissions. The most common reason, and the one most likely to repeat every time.
• A full or nearly full disk. Updates need room for the download, the unpacked files and a temporary copy.
• No route to WordPress.org. A firewall blocking outgoing connections, or a WordPress.org outage.
• An earlier update that crashed and left its lock. The next attempt finds "Another update is currently in progress".
• WP-Cron not running on time. Background updates only start when WP-Cron runs. On quiet sites, or sites that cannot make a loopback request, they start late or not at all. See WordPress missed schedule and WP-Cron and how to fix a failed loopback request.
• The host stopping a long process. Some hosts kill PHP after a time limit. An update cut off while copying files is exactly what produces a critical failure.

What about failed plugin and theme auto-updates?

When plugin or theme auto-updates fail, WordPress emails the site's admin address with a subject like "[Your site] Some plugins have failed to update", "Some themes have failed to update" or "Some plugins and themes have failed to update". The email lists each one with the versions involved and adds: "If there was a fatal error in the update, the previously installed version has been restored."

That safety net has grown over the years:

• Since WordPress 6.3, when installing a plugin or theme update fails, WordPress puts the previous version back from a temporary copy it keeps in wp-content/upgrade-temp-backup.
• Since WordPress 6.6, when a plugin auto-update causes a fatal error, WordPress rolls the plugin back to the previous version and tells you in that email.

So the site is usually fine. Open the Plugins screen, update the listed plugins by hand while watching for errors, and read what to do when a plugin update breaks your site if one does. For how the automatic update settings work in the first place, see our guide to WordPress automatic updates.

How do you stop it happening again?

• Check Site Health. Its "Background updates are working" test checks most of the conditions above, including file ownership and whether automatic updates are switched off.
• Keep free disk space, at least a few hundred megabytes beyond your backups.
• Make sure WP-Cron runs on time, ideally from a server cron job.
• Keep a recent, restorable backup. A WordPress backup you have tested turns a critical failure into a ten-minute restore.
• Read the update emails. They go to the address under Settings, then General, which is often an old inbox nobody reads. Point it at one somebody watches.

How do you keep updates working across many WordPress sites?

A background update fails quietly and emails one address. Across twenty client sites, a failure often sits unnoticed for weeks, and a site stuck after a critical failure gets no security releases until someone finally looks. That is the job WPCentrify, the WordPress management tool, does for you.

• Updates you run on purpose, not by chance. Safe updates run when you choose, on one website or many at once, and start from our request rather than waiting for WP-Cron.
• A way back for every kind of update. A WordPress core update gets a restore point first. A plugin or theme update that breaks the site is put back automatically.
• No site left on the maintenance page. If a host stops a WPCentrify update partway through, WPCentrify removes the maintenance page it left and, if the plugin or theme folder went missing, puts it back from its copy, rather than leaving visitors on "Briefly unavailable".
• Plugins left as they were. Any plugin that was on before an update run from WPCentrify is on after it, so a page builder add-on switched off by an update does not leave your pages unstyled.
• An email when an update does not install. The "Update failed" alert, on by default, tells you which website and which update, the Updates screen says why, and the website stays on the version it had.
• Every pending update on one screen, with a weekly email listing what is still waiting, oldest first.

WordPress's own background updates keep working beside WPCentrify; you choose which updates you leave to WordPress and which you run from the dashboard.

Your failed update checklist

• Home page, key pages and wp-admin checked in a private window
• Any stuck .maintenance file removed
• A fresh backup taken
• The update run again from Dashboard, Updates
• The exact error noted if it failed again
• Lock, disk space, file ownership or network fixed
• wp core update, update-db and verify-checksums run if needed
• Site Health showing background updates working and scheduled events running
• The admin email address pointed at an inbox somebody reads

Sources

• wp-admin/includes/class-wp-automatic-updater.php, WordPress source code (failure handling and the update emails)
• wp-admin/includes/update.php, WordPress source code (the failed update warning)
• wp-admin/includes/class-core-upgrader.php and wp-includes/load.php, WordPress source code (the update lock and maintenance mode)
• Configuring automatic background updates, WordPress documentation
• Updating WordPress, WordPress documentation
• wp core update and wp core verify-checksums, WP-CLI Commands

All sources checked on 7 November 2026.