Fix “Another update is currently in progress” in WordPress

Checked 11 November 2026 · WordPress 7.1.4 · PHP 8.3.6 · MariaDB 10.11.14 · WP-CLI · Read time: 5 minutes

The break · What you need · The diagnosis · The fix · Verify · If that didn’t work · What happened · Where this came from

The break

Before a core update starts, WordPress writes a lock into its options table — a row named core_updater.lock holding the current time — so two updates cannot run at the same time and corrupt each other. When the update finishes normally, WordPress deletes the row. When the update is interrupted — a timeout, a server restart, a closed browser tab — the cleanup never runs, and the row stays behind. Every later update sees it and refuses to start, with the message this guide is named for. Nothing is broken: no pages are down, no content is lost. Updates are simply blocked until the lock is gone.

This guide reproduces the break first. A disposable install had a core_updater.lock row written into its options table, the way an interrupted update leaves one. The next update attempt stopped with the message, and deleting the row let the update run to completion.

What you need

• WP-CLI, or access to the database (phpMyAdmin or your host database manager).
• Nothing else — the site is up, and the fix is one row in one table.

The diagnosis

1. Confirm the symptom

Try the update again and note the exact message. In the reproduction, the update stopped before downloading anything:

Output — core update with the lock in place

$ wp core update --version=7.1.4 --force
Updating to version 7.1.4 (en_US)...
Error: Another update is currently in progress.

The site itself was unaffected throughout — the homepage returned HTTP 200 the whole time. That is the signature of this lock: updates blocked, site fine.

2. Check the lock row

Look for the row in wp_options. With WP-CLI, one command shows it:

Command — read the lock row

wp option get core_updater.lock

In the reproduction it printed a Unix timestamp — the time the interrupted update started. In phpMyAdmin, the same check is a search for core_updater.lock in the option_name column of wp_options. If the row is there, the lock is stuck. If it is not there, the message is coming from somewhere else, and this guide is not the fix.

The lock is also time-limited: the core updater honours it for 15 minutes, then lets the next update through. The reproduction verified that too — a lock timestamp aged 16 minutes let the update proceed past the lock and start downloading. So waiting works, if you can wait.

3. Check whether the lock is stale

A lock row does not by itself mean the update died — an update that is still running holds the same row. Work out the lock's age from its timestamp: subtract it from the current time (date +%s gives the current Unix time). If the lock is less than 15 minutes old, an update may still be running — wait, and try the update again after 15 minutes. The reproduction verified the expiry the other way: a lock timestamp aged 16 minutes let the update proceed past the lock and start downloading. Only delete the row when the lock is older than 15 minutes, or when you know the update died — a timeout, a server restart, a closed browser tab. Deleting a live lock while an update is writing is how a stuck update becomes a broken one.

The fix

4. Delete the lock row

With WP-CLI, the fix is one command — once the lock is stale:

Command — delete the lock row

wp option delete core_updater.lock

Without WP-CLI, open phpMyAdmin, find the core_updater.lock row in wp_options, and delete it — or run DELETE FROM wp_options WHERE option_name = 'core_updater.lock';. In the reproduction the delete printed Success: Deleted 'core_updater.lock' option., a second read confirmed the row was gone, and the update ran to completion:

Output — core update after deleting the lock

$ wp core update --version=7.1.4 --force
Updating to version 7.1.4 (en_US)...
Downloading update from https://wordpress.org/wordpress-7.1.4.zip...
Success: WordPress updated successfully.

Verify the site is back

Load the homepage again and check the status code, and confirm the version. In the reproduction the update completed and the homepage returned HTTP 200.

If that didn’t work

Wait 15 minutes

If you cannot delete the row — no database access and no WP-CLI — wait. The lock expires on its own after 15 minutes, and the next update attempt clears it and takes a fresh one. The reproduction proved the expiry by aging the timestamp: an update attempted 16 minutes after the lock was written went straight through.

If the update fails after it starts

Once the lock is gone, a failure later in the update is a different problem — usually a download that cannot reach WordPress.org. The reproduction hit exactly that on its first retry: a proxy timeout while downloading the package, and the retry succeeded. A failed download does not re-create the lock, so do not go deleting rows again — retry the update, and check the server can reach WordPress.org.

What happened

An interrupted update left a core_updater.lock row in wp_options, and every later update refused to start. The lock was checked and found stale, then deleting that one row let the update run to completion, and the homepage stayed at HTTP 200 throughout.

Where this came from

• The lock expiring after 15 minutes, the fix — wp option delete core_updater.lock — and deleting the .maintenance file as the separate fix for the “Briefly unavailable” message, all come from Upgrading WordPress — Make WordPress Hosting.
• The lock being a timestamp row in wp_options, written by WP_Upgrader::create_lock with a 15-minute timeout for core updates, is WordPress core — read in the installed 7.1.4 source.