Skip to content

How to fix "Another update is currently in progress" in WordPress

WordPress locks its own update while one runs, and this message means the lock is set. If an update is running, let it finish. If one was cut short, WordPress honors its lock for 15 minutes, then lets the next update through. To go sooner, delete the option core_updater.lock.

By
WP Ministry
Published
Tested on
WordPress 7.1.3, PHP 8.3.35

In short

  • The attempt that printed the message changed nothing. WordPress checks the lock before it downloads anything.
  • The lock is one row in the options table, named core_updater.lock. Its value is the time the update began.
  • WordPress honors a lock for 15 minutes. After that, the next update of WordPress clears it and goes ahead.
  • When you are sure no update is running, delete the row with wp option delete core_updater.lock or one SQL statement.
  • An update that was cut short may also have left a maintenance notice or files copied in part. Running the update again finishes the job.
  • Only an update of WordPress itself checks this lock. Plugin and theme updates do not.

WordPress lets one update of itself run at a time. When an update of WordPress starts, it writes a lock into the database, and it removes the lock when the update ends, whether the update worked or failed. "Another update is currently in progress." means an update was started while that lock was in place.

The attempt that printed the message changed nothing. WordPress looks for the lock before it downloads the new version, so the site is as it was a minute ago.

There are two ways to get here. An update is running at this moment, or one was cut short and its lock is still in the database. WordPress honors a lock for 15 minutes, counted from when that update began. After that, the next update clears the old lock and goes ahead. So if an update may be running, let it finish. If nothing is running, wait out the 15 minutes or delete the lock yourself.

Where WordPress prints it

  • In the dashboard. On Dashboard, then Updates, pressing "Update to version 7.1.3" or "Re-install version 7.1.3" (with your own version number) opens a screen headed "Update WordPress". The message is the only line on it.
  • In WP-CLI. wp core update stops with "Error: Another update is currently in progress." WP-CLI 2.12.0 prints exactly that. Newer builds of the command add a hint to the same line: "You may need to run wp option delete core_updater.lock after verifying another update isn't actually running."
  • Not in a background update. An automatic update that finds the lock prints nothing. WordPress treats it as an update that was skipped, not as one that failed.

Only an update of WordPress itself checks this lock. Updating a plugin or a theme does not.

What the lock is

The lock is one row in the options table, which is wp_options unless the site uses a different table prefix. The row's name is core_updater.lock. Its value is the time the update began, as a Unix timestamp: seconds counted from the start of 1970.

WordPress does not remove an old lock on a timer. The row stays until the next update of WordPress meets it. If the lock is less than 15 minutes old, that update is refused with the message. If it is older, the update deletes it, takes a lock of its own and carries on. A row that has sat there for days stops nothing.

You may find a second row, auto_updater.lock. The background updater holds it while it works through automatic updates, and WordPress honors it for one hour. It never produces this message, and it does not stop an update you start yourself. While it is less than an hour old, automatic updates do not start.

Where it goes wrong

A page request passes through each of these in turn. This one comes from WordPress itself.

  1. Browser
  2. DNS
  3. HTTPS
  4. CDN or firewall
  5. Web server
  6. PHP
  7. WordPress (this error comes from here)
  8. Database and files

What causes it

How to fix it

Let the running update finish, or wait out the 15 minutes

  • Easy
  • No risk
  • About 15 minutes
  • Steps tested on WordPress 7.1.3

  1. Step 1: Find out whether an update is running

    Ask anyone else who can log in as an administrator, and anyone who works on the server, whether they started an update. A site that updates itself in the background may also be installing a new version right now.

  2. Step 2: Give it a few minutes

    The Updates screen carries WordPress's own note on how long an update takes: "Updates may take several minutes to complete. If there is no feedback after 5 minutes, or if there are errors please refer to the Help section above."

  3. Step 3: Reload the Updates screen

    Open Dashboard, then Updates. If "Current version" now shows the new version, the other update finished and there is nothing left to do.

  4. Step 4: Otherwise, try again when the lock is 15 minutes old

    Press "Update to version" again. If you do not know when the first update began, wait a full 15 minutes from the first time you saw the message. An attempt that is refused does not restart the count.

With WP-CLI, this prints the lock's age in minutes:

bash
echo $(( ( $(date +%s) - $(wp option get core_updater.lock) ) / 60 ))

If WP-CLI answers "Error: Could not get 'core_updater.lock' option. Does it exist?", there is no lock, and the update can be run now. When the number is 15 or more, run the update:

bash
wp core update

It ends with "Success: WordPress updated successfully.", and the lock is gone.

To undo it: Waiting changes nothing, so there is nothing to undo.

Delete the lock with WP-CLI

  • Easy
  • Low risk
  • About 5 minutes
  • Steps tested on WordPress 7.1.3

Use this when you are sure no update is running and do not want to wait. WP-CLI's manual gives the same command with the same condition: run it "after verifying another update isn't actually running."

bash
wp option delete core_updater.lock

WP-CLI answers "Success: Deleted 'core_updater.lock' option." If it answers "Warning: Could not delete 'core_updater.lock' option. Does it exist?", there was no lock: the update that held it has ended.

Then run the update again, with wp core update or with the button on Dashboard, then Updates.

Before WordPress deletes an option it looks for the row in the database itself. So this command also removes a lock that an object cache says is not there, which is the case where waiting does not help.

If WP-CLI is new to you, How to use WP-CLI covers connecting over SSH and checking that it is installed.

To undo it: There is nothing to put back. The next update writes a lock of its own and removes it when it ends.

Delete the lock in the database

  • Takes care
  • Back up first
  • About 10 minutes
  • Steps tested on WordPress 7.1.3

Without WP-CLI, remove the row with your host's database tool, such as phpMyAdmin. The same warning applies: only when no update is running.

  1. Step 1: Back up the database

    Export it from the same tool before you change anything.

  2. Step 2: Find the options table

    Its name ends in options. With the default prefix it is wp_options. If your tables begin with something else, use that name in the two statements below.

  3. Step 3: Look at the lock

    One row comes back when the lock is set, and minutes_old is how long ago the update that took it began. No row means there is no lock.

    sql
    SELECT option_name, option_value, FLOOR((UNIX_TIMESTAMP() - option_value) / 60) AS minutes_old FROM wp_options WHERE option_name = 'core_updater.lock';

  4. Step 4: Delete it

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

  5. Step 5: Run the update again

    Open Dashboard, then Updates, and press "Update to version" once more.

To undo it: Nothing needs putting back, because the next update writes a lock of its own. If a statement removed anything else, restore the database backup.

Finish the update that was cut short

  • Takes care
  • Back up first
  • About 15 minutes
  • Steps tested on WordPress 7.1.3

An update that stopped partway can leave more than its lock behind. Once the lock is gone, or 15 minutes old, run the same update through to the end.

  • A maintenance notice. While WordPress copies its new files it puts the site into maintenance mode. An update that dies there leaves every page, the dashboard included, reading "Briefly unavailable for scheduled maintenance. Check back in a minute." WordPress stops obeying that notice after ten minutes, and the page for that message shows how to end it sooner.
  • Files copied in part. WordPress copies the file that holds its version number last, so that a failed update still reports the old version. The site therefore still offers the update, and running it copies WordPress's files again from the start.

  1. Step 1: Take a backup if you can

    How to safely update WordPress, plugins and themes covers what to back up and how to check that the backup is usable.

  2. Step 2: Run the update again

    Open Dashboard, then Updates, and press "Update to version". If the screen says "You have the latest version of WordPress." and the site still misbehaves, press "Re-install version" on the same screen to copy WordPress's own files into place again.

  3. Step 3: Look at the site

    Open the home page and the dashboard. Both should load, and "Current version" on the Updates screen should show the new version.

With WP-CLI, the first command runs the update. The second compares WordPress's own files with the checksums WordPress.org publishes:

bash
wp core update
wp core verify-checksums

The second command should end with "Success: WordPress installation verifies against checksums." WP-CLI can run the update while the maintenance notice is still showing, and the update removes the notice when it finishes.

If the site shows an error of its own afterwards, "There has been a critical error on this website" shows how to find the line behind it, and A WordPress update went wrong: a runbook puts the whole recovery in order.

To undo it: Restore the backup you took before running the update again.

When to get help

If every run of the update dies and leaves a new lock, or the site shows a different error once the lock is gone, the trouble is the update and not the lock. A time or memory limit, files WordPress may not write, or a copy of WordPress left half-installed each need the server's error log and access to its files.

Common questions

Is it safe to delete core_updater.lock?

Yes, when no update is running. The row holds a time and nothing else, and WordPress writes a new one at the start of the next update. If an update is running, deleting the row lets a second one start on top of it, so check first.

Does the lock affect my visitors?

No. The lock stops a second update and does nothing else, and the site loads as usual while it is set. Visitors notice only when the update that left the lock also left the site in maintenance mode.

Why does the message come back every time I try?

Each update takes a new lock when it starts. If the update dies partway every time, each attempt leaves a fresh lock, and the next one meets it. Find out what stops the update. The server's error log is the place to look. An update that runs into a time limit or a memory limit ends this way. If the lock is more than 15 minutes old and the message still appears, an object cache is out of step with the database, and deleting the row clears it.

What is auto_updater.lock?

The background updater's own lock, which WordPress honors for one hour. It never causes this message. A stale one keeps automatic updates from starting until it is an hour old, and it can be deleted the same way once you know no background update is running.

More on this subject

Would you rather we fixed it?

Quick Fix is $49. One issue, one site, up to about an hour. No fix, no fee. 30-day warranty. It starts with a free diagnosis.

Get a free diagnosis