You click Update on Dashboard > Updates and WordPress answers with “Another update is currently in progress.” Or wp core update stops with the same line. Either way, the core update never starts.
Bad timing for it. WordPress 7.1.4, released October 28, 2026, is a security release with 22 fixes, and the fixes were backported to older branches down to 4.7. You want that update in, not a lock message. The fix is one row in wp_options.
What the lock is and where it lives
Before a core update starts, Core_Upgrader calls WP_Upgrader::create_lock( 'core_updater', 15 * MINUTE_IN_SECONDS ). That inserts an option named core_updater.lock into the options table, with the current Unix timestamp as its value.
When the update finishes or fails cleanly, WordPress deletes the option. If PHP dies halfway through (a timeout, the memory limit, a full disk), that cleanup never runs and the row stays behind.
Automatic background updates use a separate lock, auto_updater.lock, with the default timeout of one hour. While that one is set, background updates just skip their run without telling you.
Wait 15 minutes first, unless the lock never expires
create_lock() treats a lock older than its timeout as stale. After 15 minutes, the next Update click releases the old lock and takes a new one. So the cheapest fix is to wait a quarter of an hour and try again.
There is one case where waiting does nothing. create_lock() reads the existing lock with get_option(), and if that comes back empty, it returns false without ever checking the age.
So an empty option_value, or a persistent object cache (Redis, Memcached) that is out of sync with the database, gives you a lock that blocks every update forever. That case, and the “it’s a security release, I’m not waiting” case, need the manual fix.
Step 1. Back up the database
You are about to delete rows from wp_options, so take a backup first. From the WordPress root:
wp db export before-lock-fix.sqlWP-CLI prints a Success line with the file name. Move that file out of the web root when you’re done.
Step 2. Make sure no update is really running
Deleting the lock while a real update is copying files is how you end up with half-updated core files. Check the lock’s value and the current time:
wp option get core_updater.lock
date +%sBoth are Unix timestamps. If the lock is only a minute or two old, someone (or something) may be updating right now, so give it time. If WP-CLI says the option doesn’t exist, there is no core lock and your problem is further down this post.
Step 3. Delete the lock
wp option delete core_updater.lock
wp option delete auto_updater.lockEach command reports Success when it removes the option. A warning on the second one just means the background lock wasn’t set.
No WP-CLI? Run this in phpMyAdmin instead:
DELETE FROM wp_options
WHERE option_name IN ('core_updater.lock', 'auto_updater.lock');💡 Replace wp_ with your table prefix. You’ll find it in $table_prefix in wp-config.php.
Step 4. Flush the object cache
wp cache flushOn a site without a persistent object cache this changes nothing, so it’s safe either way. On a site with Redis or Memcached, this is the step that matters. Deleting the row with SQL doesn’t touch the cache, and WordPress may keep reading the old value from there.
Step 5. Run the update again
wp core update
wp core update-db
wp core versionThe last command should print the new version, 7.1.4 if you’re on the 7.1 branch. You can also go back to Dashboard > Updates and click the button again.
When the lock keeps coming back
A lock that returns after every attempt means the update itself keeps dying. The lock is only the symptom. The usual suspects:
- PHP
max_execution_timeormemory_limittoo low to unpack and copy the update package - A full disk or account quota, covered in disk quota full: fix HTTP 500 and failed updates
- File ownership or permissions that stop PHP from writing to
wp-adminandwp-includes
Turn on logging and look at the last fatal error right after a failed attempt. If nothing gets written, debug.log not being created walks through why.
If only automatic updates are stuck and manual ones work, check WP-Cron. Background updates run from cron, and a broken loopback means they never start. That one is in loopback request failed: fix WP-Cron status code 0.
Remove a leftover .maintenance file
A failed update can also leave a .maintenance file in the WordPress root. Visitors then get “Briefly unavailable for scheduled maintenance. Check back in a minute.” with a 503 status.
WordPress ignores that file once its timestamp is 10 minutes old, but I still delete it after a broken update so nothing gets confused:
rm .maintenanceThen run the update again. An update that died halfway may have replaced only some core files, and a complete run puts them all on the same version.
On OpenPanel, the WordPress Manager shows a badge when a core update is available and has a button to run it. The same screen has a maintenance mode toggle and a phpMyAdmin link on the Overview tab, so you can check the wp_options row and retry the update without leaving the panel. In cPanel you usually do the same through phpMyAdmin and the File Manager, or WP Toolkit if your host installed it.
TL;DR: “Another update is currently in progress” comes from the core_updater.lock option in wp_options. It normally expires after 15 minutes. If it doesn’t, or you can’t wait for a security release like 7.1.4, back up the database, confirm nothing is updating, run wp option delete core_updater.lock, flush the object cache and update again. If the lock keeps returning, fix whatever is killing the update: limits, disk space or permissions.
