Another Update Is Currently in Progress: Fix the Stuck WordPress Update Lock (2026)

Key facts at a glance

WordPress stuck-update recovery in 2026

Last updated June 30, 2026

What it actually is: A leftover lock, not a real update. WordPress sets a core_updater.lock row in wp_options when an update starts and deletes it when it ends. An interrupted update leaves the lock, so WordPress keeps blocking new updates.
Try this first: Wait 15 minutes, then reload. Since WordPress 4.5 the core updater sets this lock with a 15-minute expiry, so a lock older than that is treated as stale and ignored, and the message usually clears on its own.
The one-line fix: Delete the single lock row. With WP-CLI it is wp option delete core_updater.lock, or remove the core_updater.lock row in phpMyAdmin. It touches no content and is safe.
The sibling error: Destination folder already exists is the same cause at a different stage. A failed plugin or theme update left a folder behind. Delete it, or upload the zip and choose Replace current with uploaded.
Why updates get interrupted: Anything that kills the PHP request mid-update: a short execution timeout, a low memory limit, a dropped connection, the host ending the process, or closing the browser tab before it finished.
Finish the job, not just the symptom: After clearing the lock, re-run the update so files land on one consistent version, clear any maintenance screen, and raise the limit that caused the interruption so it does not recur.

Source: the WordPress developer reference for WP_Upgrader::create_lock and Core_Upgrader::upgrade, the WP-CLI option command, the WPBeginner guide to the destination-folder error, and our hands-on stuck-update repairs. Get a quote in 60 seconds →

What the lock is and why it sticks

WordPress updates one thing at a time on purpose. If two updates ran at once, say an automatic update firing while you started a manual one, they could overwrite each other halfway and corrupt the site. To prevent that, WordPress uses a simple lock. The moment a core update begins, it writes a single row to the wp_options table named core_updater.lock, and the value it stores is the timestamp of when the update started. While that row exists and is recent, any other update that tries to start checks the lock, sees one in place, and politely bails out with the message you are reading.

In the normal case this is invisible. The update runs, finishes, and WordPress deletes the lock as its last step, so the next time you visit the Updates screen there is no lock and everything works. The error appears only when that last step never runs. If the update is interrupted partway through, the request is killed before it can delete the lock, and the row is orphaned. WordPress has no way to know the update actually died, so it keeps reading the leftover lock as a live update and keeps showing the message. Nothing is really updating. You are looking at the ghost of an update that already failed.

That is why the fix is not to wait endlessly or to reinstall anything. It is to remove the one stale row, after confirming an update is not genuinely still running, and then to re-run the update that failed so the files finish landing on a single version. The rest of this page covers the safe ways to clear the lock, the closely related Destination folder already exists error, and how to stop the interruption that caused it from happening again.

Two errors, one root cause

These two messages show up in the same situations, an update that did not finish, but they fail at different stages and are cleared differently. Knowing which one you have tells you exactly where to look.

Another update is currently in progress

A stale database lock. The core_updater.lock row in wp_options was left behind by an interrupted core update. The fix is to wait for the 15-minute expiry or delete that one row. No files are involved.

Destination folder already exists

A leftover folder on disk. A failed plugin or theme install left a folder in wp-content/plugins or wp-content/themes, and the next attempt will not overwrite it. The fix is to remove that folder or replace it on upload. No database row is involved.

Both come from the same kind of failure, an update killed before it could finish, which is why they often appear together after the same bad night of auto-updates. If you are seeing one, it is worth checking for the other, and for the two common knock-on effects, a stuck maintenance screen and a half-updated plugin throwing a critical error.

Which symptom matches yours

Find the row that matches what you see. Each one points to a specific cause and fix.

Symptom	Most likely root cause
The Updates screen shows "Another update is currently in progress."	A stale core_updater.lock row was left in wp_options by an interrupted core update. Wait 15 minutes for it to auto-expire, or delete the row to clear it now.
It is still showing the message more than 15 minutes later	The lock should have auto-expired, so either an auto-update is recreating it or a cache is serving you the old screen. Delete the lock, purge caches, and check for a looping update.
"Installation failed: Destination folder already exists" when installing a plugin	A failed previous attempt left a folder in wp-content/plugins. Delete that leftover folder, or upload the zip and choose Replace current with uploaded.
The same Destination folder error on a theme	A leftover folder in wp-content/themes from an interrupted theme update. Remove it over SFTP, or use the replace-on-upload option.
A core or plugin update bar hung and now nothing will update	The interrupted update left the lock in place, so WordPress blocks every new update. Clearing the lock restores updating.
Alongside this you also see a maintenance screen or a critical error	The same interrupted update left a .maintenance file or a half-updated plugin. Clear the lock, then handle the maintenance screen and check the debug log.

The root causes

Stuck-update errors come down to a small set of causes, all tracing back to an update that did not complete.

1. A stale core_updater.lock left in the database

The direct cause of Another update is currently in progress. The interrupted core update never deleted its lock row, so WordPress still reads it as a live update. Removing the core_updater.lock row, or waiting for its 15-minute expiry, clears the message.

2. A leftover plugin or theme folder

The direct cause of Destination folder already exists. A failed install or update left a folder in wp-content/plugins or wp-content/themes, and WordPress will not overwrite it on the next attempt. Removing the leftover folder, or replacing it on upload, lets the install finish.

3. Whatever interrupted the update in the first place

The deeper cause, and the one that makes it recur. Updates download, unpack, and copy files in a single PHP request, and that request can be cut short by a short max_execution_time, a low memory limit, a dropped connection, the host killing a long-running process, or someone closing the tab. Raising the limits so the update finishes in one pass is what stops the lock from coming back.

4. A looping auto-update recreating the lock

When the message survives past 15 minutes, an automatic update that keeps retrying in the background can set the lock again on each run, so it never appears to clear. The fix is to clear the lock, then resolve why the auto-update keeps failing, usually the same limit problem above, rather than fighting the symptom.

5. A cache serving the old in-progress screen

Sometimes the lock is already gone but a caching plugin, host page cache, or CDN keeps serving you the cached in-progress page, which looks identical to a stuck lock. Purging caches after clearing the lock makes sure you are looking at the live state of the admin.

6. Collateral from the half-finished update

The same interruption often leaves two side effects: a leftover .maintenance file showing the maintenance screen, and a plugin left half-updated that now throws a critical error, which the debug log will name. Clear the lock first, then handle these.

The 15-minute expiry detail

This is the detail that decides whether you need to do anything at all, and most guides skip it. The lock is not permanent. When the core updater creates it, it sets a 15-minute expiry, so the lock is only honored while it is recent. WordPress treats any core_updater.lock older than 15 minutes as stale, ignores it, and lets a new update proceed. This behavior has been in place since WordPress 4.5, and it is why the single best first step is simply to wait.

So if your update hung a few minutes ago, the cleanest fix is to wait until a full 15 minutes have passed from that moment, then reload the Updates screen. In the great majority of cases the message is gone and you can re-run the update. You never had to touch the database. The reason to act sooner is impatience, urgency on a live site, or the cases where the message refuses to clear well past the window, which means the lock is being recreated or a cache is hiding the real state.

The rule of thumb

Under 15 minutes, wait, it will likely clear itself. Need it gone now, delete the core_updater.lock row safely. Still stuck well past 15 minutes, the lock is not the whole story, so delete it, purge every cache, and check whether an auto-update is looping or the update keeps failing on a resource limit.

DIY vs hand it off

Clearing the lock is genuinely a self-fix for most people. Where it gets worth handing off is when the update keeps failing, or it left the site half-broken. If the left column matches you can likely do this. If the right column matches, get help.

✓

Realistic on your own

✓You can wait 15 minutes and the message clears
✓You can run one WP-CLI command or delete one phpMyAdmin row
✓It is the destination-folder error and you know which folder is the leftover
✓The site is otherwise working, just blocked from updating
✓The update succeeds cleanly once the lock is gone
✓You are comfortable using SFTP or your host file manager

✗

Hand it off, save the time

✗The lock keeps coming back no matter how often you delete it
✗The update fails the same way every time you retry
✗The site is also stuck in maintenance mode or showing a critical error
✗You are not sure which leftover folder is safe to delete
✗It is a live store and you cannot risk a wrong database edit
✗You want the underlying resource limit fixed so it stops recurring

How to diagnose it

Work in this order. The first step solves it for most people with no risk at all.

Wait a full 15 minutes, then reload

The core update lock auto-expires after 15 minutes since WordPress 4.5. If the hang was recent, waiting and reloading the Updates screen usually clears Another update is currently in progress on its own.

Identify which error you actually have

A message on the Updates screen is the database lock. Installation failed: Destination folder already exists when installing a plugin or theme is the leftover-folder error, fixed a different way.

For the lock, delete the core_updater.lock row

With WP-CLI run wp option delete core_updater.lock, or in phpMyAdmin open wp_options, find the row whose option_name is core_updater.lock, and delete that one row.

For the folder error, find the leftover folder

Over SFTP, look in wp-content/plugins or wp-content/themes for a folder named after the plugin or theme you were installing. That leftover is what is blocking the install.

If it survives 15 minutes, check cache and auto-updates

Purge any caching plugin, host cache, and CDN so you see the live admin, and check whether an automatic update is retrying in the background and recreating the lock.

Check for collateral from the failed update

If the site also shows a maintenance screen or a critical error, the same interruption left a .maintenance file or a half-updated plugin. Read the debug.log to name it.

How to fix it

Each branch stands alone. Pick the one your diagnosis pointed to. Back up the database before any SQL, and use your real table prefix in place of wp_.

Delete the stale update lock

With SSH and WP-CLI this is a single command. It removes only the lock row and touches no content.

# Remove the stale lock
wp option delete core_updater.lock

Without WP-CLI, do the same thing in phpMyAdmin with one query, or by finding the row and clicking Delete.

DELETE FROM wp_options WHERE option_name = 'core_updater.lock';

Reload the Updates screen and re-run the update that failed, ideally one item at a time.

Clear "Destination folder already exists"

The safest method, since WordPress 5.5, is to upload the zip and let WordPress replace the existing copy.

Plugins -> Add New Plugin -> Upload Plugin -> choose the .zip
WordPress detects the existing copy
-> click "Replace current with uploaded"

Or remove the leftover folder directly over SFTP, then retry the install from the dashboard.

# Over SFTP, delete the leftover folder, then reinstall
wp-content/plugins/PLUGIN-NAME    <- delete this folder
wp-content/themes/THEME-NAME      <- or this, for a theme

Stop it from coming back

If the update keeps failing and recreating the lock, give it enough resources to finish in one pass. Raise the memory limit in wp-config.php, and ask your host to raise the execution time if it is very low.

// In wp-config.php, above the stop-editing line
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '256M' );

Then update one plugin or theme at a time rather than in a big bulk run, and do not close the tab until each finishes.

Clean up the collateral

If the failed update also left side effects, handle them after the lock is gone. A stuck maintenance screen is a leftover .maintenance file in the site root, covered on our maintenance mode fix. A critical error from a half-updated plugin is named in the debug log, then re-run that plugin update cleanly.

Lock keeps returning, update keeps failing, or the site is half-broken?

Let us finish the update in 2 hours →

A real stuck-update session

A composite from the stuck-update repairs we run most weeks, with identifying details removed.

Scenario

A site owner came back to a dashboard that said Another update is currently in progress and would not let them update anything. They had waited over an hour and even tried deleting the lock once through a plugin, but within minutes the message returned. Plugins were also a version behind and refusing to update.

Diagnosis

The lock was being recreated. Overnight, an automatic update had started, and the host had killed the PHP process at a low memory limit before it finished, leaving the lock. The site auto-updater kept retrying through WP-Cron, hitting the same memory wall each time, and re-setting core_updater.lock on every run, which is why deleting it once did nothing.

Resolution

We deleted the core_updater.lock row, raised the memory limit so an update could complete in one request, then ran the core and plugin updates manually one at a time so the retrying auto-update was not competing. With enough memory the update finished cleanly, deleted its own lock, and the message did not return. We confirmed no maintenance file or half-updated plugin was left behind.

⏱

Total elapsed

Updates flowing again well inside the 2-hour window, once the memory limit let the update finish in one pass.

When to stop and hand it off

Clearing the lock is a quick self-fix, so hand it off only when it is not behaving like a quick fix. First, the lock keeps coming back however often you delete it, which means an update is looping on a resource limit that needs raising. Second, the update fails the same way every retry, so the real problem is the interruption, not the lock. Third, the same failed update left the site in maintenance mode or throwing a critical error and you have more than one thing to untangle. Fourth, it is a live store and you do not want to risk a wrong database edit. We clear the lock or leftover folder, find and raise the limit that caused the interruption, re-run the update so files land on one version, and clean up any maintenance screen or half-updated plugin. Flat $49 to $149, done in two hours when scope fits, money back if we cannot.

Get a quote in 60 seconds

Stuck WordPress update FAQ

What does "Another update is currently in progress" actually mean?

It means WordPress thinks a core update is still running, because a lock it sets at the start of an update was never cleared at the end. When WordPress begins a core update it writes a row to the database called core_updater.lock, holding the time the update started, so that no second update can start on top of the first. Normally WordPress deletes that row the moment the update finishes. If the update was interrupted, by a server timeout, a memory limit, a dropped connection, or someone closing the browser tab, the second half never runs and the lock is left behind. The next time you open the Updates screen, WordPress sees the lock, assumes an update is still going, and shows this message. The site is not really updating anything. It is just guarding against a collision that already ended badly.

Will it clear by itself if I just wait?

Usually yes, and waiting is the safest first move. Since WordPress 4.5 the core updater sets that lock with a 15-minute expiry, so it treats any core_updater.lock older than 15 minutes as stale and ignores it. In practice that means if you wait a full 15 minutes from when the update first hung and then reload the Updates screen, the message normally clears on its own and you can try the update again. If you are still seeing it well past 15 minutes, the lock is either being recreated by something that keeps retrying the update, or you are looking at a cached copy of the old screen. So step one is patience, and only if it outlasts the 15-minute window do you need to delete the lock by hand or look at what is re-triggering it.

How do I delete the core_updater.lock without a working dashboard?

You remove the single database row, and there are three ways depending on what access you have. With WP-CLI over SSH it is one command, wp option delete core_updater.lock, which is the cleanest path. With phpMyAdmin or your host database tool, open the wp_options table, find the row whose option_name is core_updater.lock, and delete just that one row, nothing else. And if you would rather not touch the database, there are small free plugins built only to delete this lock with one click. All three do the same thing, removing the stale lock so WordPress stops believing an update is in progress. None of them touch your content, so deleting the lock is safe. After it is gone, reload the Updates screen and re-run the update that failed, ideally one item at a time.

Is "Destination folder already exists" the same problem?

It is a close cousin from the same root cause, an interrupted update, but it fails at a different stage and is fixed differently. The full message is usually Installation failed: Destination folder already exists, and it appears when you install or update a plugin or theme. WordPress installs by unpacking the new version into a folder named after the plugin or theme, and if a previous attempt died part way through, it can leave that folder behind. The next attempt tries to create a folder that is already there, refuses to overwrite it blindly, and stops with this error. So where the update lock is a stale database row, this one is a leftover folder on disk. The fix is to remove that leftover folder, or to upload the plugin or theme zip and let WordPress replace the existing copy. Both clear the obstruction so the install can finish.

How do I fix "Destination folder already exists" safely?

Two reliable methods. The first, and the one most people should use, is to upload the zip and choose to replace. Since WordPress 5.5 you can go to Plugins then Add New Plugin or Appearance then Themes, upload the plugin or theme zip, and when WordPress notices a copy is already installed it offers a Replace current with uploaded button that cleanly overwrites the old folder. The second method is to delete the leftover folder directly, over SFTP or your host file manager: go to wp-content/plugins or wp-content/themes, find the folder named after the plugin or theme you were installing, and delete that one folder, then retry the install from the dashboard. Deleting the folder of a plugin that is not active will not harm your content, but if you are unsure which folder is the leftover, the replace-by-upload method is safer because WordPress decides what to overwrite.

It is still stuck more than 15 minutes later. Why has the lock not cleared?

When the message outlives the 15-minute window, one of two things is usually happening. Either something keeps recreating the lock, or you are not actually seeing a live page. A scheduled or automatic update that keeps retrying in the background can set the lock again each time it runs, so it never appears to clear. And a caching layer, a caching plugin, a host page cache, or a CDN, can keep serving you the old in-progress screen long after the real state has changed, which looks identical to a stuck lock but is just a stale cache. The way through is to delete the lock by hand, then purge every cache so you are looking at the live admin, and then check whether an auto-update is looping. If updates keep failing the same way, the underlying interruption, often a low memory limit or a short execution timeout, needs raising so the update can finish in one pass.

Did deleting the lock break anything, since the update did not finish?

Deleting the lock itself is harmless, but the interrupted update may have left the site half-updated, and that is worth checking. The lock is only a flag. Removing it does not change any code or content, it just tells WordPress no update is running. The real risk is the update that failed midway, which can leave a mix of old and new files, a leftover .maintenance file showing the maintenance screen, or a plugin that is partly upgraded and now throws an error. So after you clear the lock, the right move is to re-run the same update cleanly so the files end up at a single consistent version, and if the site shows a maintenance screen or a critical error, address that next. We routinely clear the lock and then verify the update actually completed rather than leaving it in the half-done state that caused the lock in the first place.

Can you clear this and make sure the update finishes properly?

Yes, and that second half is the part worth paying for. Deleting the lock or the leftover folder is quick, but the failure that caused it tends to recur if nothing changes. We remove the stale core_updater.lock or the leftover plugin or theme folder, confirm whether the interrupted update left the site half-updated or in maintenance mode, re-run the update so every file lands on one consistent version, and fix the underlying interruption, usually a memory limit or execution timeout that was too low for the update to finish in one request. We also check that an auto-update is not looping and recreating the problem. You get the site updated cleanly and the cause removed, not just the symptom cleared. Flat $49 to $149, done in two hours when scope fits, money back if we cannot.

Sources and further reading

Every technical claim on this page traces back to the WordPress developer reference, the WP-CLI documentation, or the named guide.