How to Fix “An Automated WordPress Update Has Failed to Complete”

wp-admin can make this sound worse than it is. The warning “an automated WordPress update has failed to complete” usually means WordPress began an update and didn’t finish its cleanup.

Sometimes the public site still works, and the dashboard is holding onto an old warning.

Sometimes visitors see WordPress’s scheduled-maintenance screen. And sometimes that screen is covering up a real update failure underneath.

The easy mistake is stopping once the warning disappears. Deleting .maintenance can make the site reachable again, but it doesn’t prove the update completed. I treat this warning as two jobs: restore access, then confirm WordPress isn’t half-updated.

Check the site first

Open the public site before you touch files. Use an uncached view if you can: incognito mode, a different browser, or mobile data. You’re trying to sort the problem into one of these states:

• The public site loads, but wp-admin shows the failed update warning.
• Visitors see the scheduled-maintenance screen.
• The site shows a critical error.
• WordPress says an update process is already running.

Those need different responses. A maintenance message usually points to .maintenance. A critical error points more toward a broken plugin, theme, or partial file replacement. If only wp-admin is complaining, you have more time to verify before making bigger changes.

Don’t mash the update button again. If the first attempt failed because WordPress couldn’t write files, ran out of disk space, or hit a timeout, a second attempt usually fails in the same place.

Backup before file work

Yes, the immediate fix is often one tiny file. Make the backup anyway.

The risk isn’t that .maintenance is precious. It isn’t. The risk is that you’re about to work inside the folder with wp-config.php, .htaccess, and the site’s plugin files. A current backup gives you a way to roll back if you delete the wrong thing or discover the update failed more seriously than the warning suggested.

If your host already keeps backups, check the newest available restore before you start. For a business site, this is where a backup tool earns its place: you can make the file-level fix with a restore path instead of trusting that “there’s probably a backup somewhere.”

Delete only .maintenance

During an update, WordPress creates .maintenance, a hidden file in the main install folder. That’s where wp-admin, wp-content, and usually wp-config.php sit together. On many hosts it’s public_html, but the folder name matters less than those WordPress files.

When the update finishes, WordPress removes .maintenance. If the update gets interrupted, the file can remain and keep visitors on the maintenance screen. You can remove it in either of these ways:

• Hosting file manager: Open the main WordPress folder, turn on the setting for hidden files or dotfiles, find .maintenance, and delete that file only.
• FTP/SFTP: Connect with a client such as FileZilla or Cyberduck, open that same folder, make hidden files visible if needed, and delete .maintenance.

Be deliberately boring here. Don’t delete .htaccess. Don’t edit wp-config.php. Don’t rename plugin folders as part of this step. You came for one file.

Reload the site from an uncached browser session after deleting it. If the public site comes back, you’ve cleared the stuck maintenance state. Now you need to prove the update state is clean.

Clear cache and verify

Clear the caches that can actually serve old pages: caching plugin, host cache, CDN, or all of them if your site uses more than one. Browser cache can confuse the view, but it doesn’t cause a server-side WordPress update to fail.

Open Dashboard > Updates next.

Check three things:

• The warning is gone.
• The WordPress version and update screen make sense.
• Any failed plugin, theme, or WordPress update is either completed or still clearly pending.

Open Tools > Site Health after that. I pay attention to warnings about writable directories, loopback requests, scheduled tasks, and temporary backup folders because those are the kinds of things that break updates again next week.

If the front end works, wp-admin works, Dashboard > Updates is clean, and Site Health isn’t complaining about update infrastructure, you’re probably done. If the same update is still waiting, the update didn’t finish. Removing the warning was only the first repair.

If .maintenance isn’t there

First, make sure you can see hidden files. A quick clue is .htaccess. If you can’t see .htaccess either, your file manager may be hiding dotfiles. If hidden files are visible and .maintenance still isn’t there, don’t create one. Don’t delete a different file because it looks suspicious. Move back into diagnosis:

• If WordPress says it’s up to date, clear every cache and check again in a fresh session.
• If the same update is still available, treat it as an incomplete update.
• If WordPress reports an update already in progress, wait a little. If it stays stuck, send the message to support or a developer and ask them to check the updater lock.

Plenty of tutorials get risky right here. A missing .maintenance file isn’t an invitation to poke around the database from a blog post. It means the problem probably isn’t simple maintenance mode anymore.

Why the update failed

Automatic updates are more physical than they feel. WordPress downloads the update package, unzips it, writes new files, and cleans up the temporary state. The dashboard warning is vague because any break in that chain can end with the same message.

The next checks are the ones that usually explain the repeat failures.

Permissions or ownership

WordPress file permissions are the big one after migrations, restores, server moves, or manual uploads. WordPress may be able to read the site but fail when it tries to write new files.

Clues:

• Errors about copying files or denied permissions
• WordPress asking for FTP credentials
• Every update failing at the same step

What to do:

• Don’t set everything to 777. That’s a security problem, not a repair plan.
• Typical WordPress installs use folders around 755 and files around 644, but ownership matters just as much.
• Send the exact error to your host and ask them to check file ownership and write access for WordPress updates.

Low storage

Updates need room to download and unpack files. A hosting account near its disk limit can stop the update halfway through or trigger a failed to write file to disk error.

Check disk usage in your hosting panel. Also look at wp-content/upgrade for old update folders, and take Site Health warnings about temporary backup folders seriously. WordPress uses temporary update areas during safer plugin and theme updates, so a writable-temp-folder warning isn’t cosmetic.

Don’t empty update folders while an update is running. If you’re not sure, wait, back up the site, and ask the host what is stale.

PHP limits

On smaller hosting plans, PHP can run out of memory or time while unpacking a core update or replacing a large plugin. Open the error log around the failure time. These lines are worth paying attention to:

• memory exhaustion errors
• maximum execution time errors
• failed unzip or copy messages

If you find one, raise the relevant PHP memory or execution limit in your hosting tools. If you can’t change it yourself, send that log line to support. Retrying before the limit changes is mostly just recreating the same failure.

Plugin or theme breakage

Plugins and themes don’t cause every automated update failure. I only put them near the top when the maintenance screen is gone and the site now shows a fatal error, wp-admin won’t load, or the error log names a specific plugin or theme.

If wp-admin works, deactivate plugins temporarily and test with one of the default themes. If wp-admin doesn’t work, check your inbox for the recovery mode email. When the log names one plugin or theme, renaming that folder over SFTP can restore access.

Go slowly. A critical error after a failed update can mean some files changed and others didn’t. The goal is to get access back, then update cleanly.

If the error points toward the active theme instead, the Themes screen is the next place to verify what WordPress is running.

Stale update locks

The “update already running” message is related, but it isn’t just a leftover .maintenance file. WordPress can leave an updater lock behind after a failed attempt.

Wait first, because real locks can expire. If the message doesn’t clear, have support or a developer inspect the lock. I wouldn’t tell a non-technical site owner to edit database options while the site is already unstable.

Less common causes

A few failures only show up in logs:

• A host migration left core files modified.
• OPcache is serving old PHP after files changed.
• A server rule or firewall blocked a download or file write.
• A manual upload was interrupted.

You don’t need to chase these first. But if the normal checks don’t explain the failure, stop doing dashboard retries and get the logs reviewed. At that point, a clean manual core reinstall or host-side fix is safer than another blind automatic update.

Retry the update carefully

Retry only when the site is out of maintenance mode and you’ve removed the likely blocker.

Run one update first, not every pending update at once. If a plugin update failed, update that plugin by itself. If several plugins are waiting, use small batches so you can see which one breaks. For a failed core update, go back through the file access, storage, PHP, and log checks before trying again.

If automatic updates keep failing, manual updating may be the next move. For WordPress core, that usually means downloading a fresh copy from WordPress.org and replacing core files over SFTP while preserving wp-content and wp-config.php.

That’s normal maintenance work, but don’t make a live site your first attempt. If you haven’t done it before, bring in host support or a developer.

What to send your host

Support has a much better chance when your ticket includes specifics. Send this:

• The exact warning: “An automated WordPress update has failed to complete.”
• What visitors see: normal site, maintenance screen, critical error, or something else.
• Whether .maintenance existed and whether you deleted it.
• What failed: core itself, one plugin, or a theme.
• Current WordPress and PHP versions, if wp-admin shows them.
• Any error-log lines from the time of the update.

Start with ownership and write access. Next, ask them to match the update time against the server logs and tell you whether a limit, cron issue, loopback failure, or stuck updater lock blocked WordPress.

Avoid the next failed update

I wouldn’t turn off automatic updates forever because one update failed. Security releases still matter, and a site that never updates usually becomes more fragile, not safer.

The better setup is simple: keep offsite backups, make sure one actually restores, update important sites on staging first, and don’t let plugin updates pile up for months. Watch Site Health for writable-folder, cron, loopback, and temporary-directory warnings. Those warnings are boring until they’re the reason the next update fails.

For routine upkeep, a WordPress security maintenance checklist is more useful than trying to remember these checks only after an update gets stuck.

And if the same host keeps failing updates because of permissions or timeouts, treat that as a hosting problem. WordPress updates shouldn’t be dramatic every time.

FAQs