You click "Update" in WordPress, and instead of a progress bar you get a flat refusal: "Another update is currently in progress." You wait ten minutes. Same message. Nothing is actually updating, and now you can't update anything. We see this ticket a lot, and the fix usually takes under two minutes once you know where WordPress hides the lock.

Symptom: what you're seeing

  • Dashboard → Updates shows "Another update is currently in progress" when you try to update core.
  • The same message appears even though no update is visibly running.
  • Sometimes the site is also stuck in maintenance mode (see our guide on the "briefly unavailable for scheduled maintenance" message).
  • Plugin or theme updates may still work, while core updates refuse to start.

Cause: a lock that never got released

Before WordPress updates core files, it sets a lock so two updates can't collide. That lock is a single row in your database, in the wp_options table, with the option name core_updater.lock. The value is a timestamp. If the lock is younger than 15 minutes, WordPress refuses to start another update.

Normally the lock clears itself when the update finishes. It gets stranded when the process dies halfway. Common reasons:

  • PHP hit max_execution_time or the memory limit mid-update.
  • You closed the browser tab or lost connection during the update.
  • An auto-update was running via WP-Cron at the same moment you started a manual one.
  • A resource limit (CPU, entry processes, I/O) killed the PHP process on shared hosting.
  • An object cache such as Redis or Memcached kept a stale copy of the lock after you deleted it from the database.

The lock normally expires on its own after 15 minutes. If it still shows after that, something is re-creating it or a cache is serving the old value.

Fix 1: wait, then retry (the lazy way)

Give it a full 15 minutes with no one clicking anything, then reload Dashboard → Updates. If the lock was the only problem, it's gone. If you see the message again after that, move on to Fix 2.

Fix 2: delete the lock from the database

In cPanel, open phpMyAdmin, select your WordPress database, and run this in the SQL tab. Replace wp_ with your actual table prefix if it's different.

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

Reload the Updates page and try again. Don't worry if it says 0 rows affected; that just means the lock had already expired and the real cause is elsewhere (Fix 3 or 4).

Prefer the terminal? Use WP-CLI

If you have SSH access, WP-CLI does the same thing without opening phpMyAdmin:

cd ~/public_html
wp option delete core_updater.lock
wp core check-update

Fix 3: clear the object cache

If you run Redis, Memcached, or a caching plugin with an object cache drop-in (wp-content/object-cache.php), WordPress may read the lock from cache instead of the database. Flush it:

wp cache flush

No WP-CLI? Use the flush option in your caching plugin, or temporarily rename wp-content/object-cache.php to object-cache.php.off in File Manager, update, then rename it back.

Fix 4: check for a half-finished update

A stranded lock often comes with leftovers. Check these in File Manager:

What to checkWhereWhat to do
Maintenance flagpublic_html/.maintenanceDelete it if the site shows the maintenance message
Leftover upgrade folderwp-content/upgrade/Delete the contents (not the folder)
Disk quotacPanel → Disk UsageFree space if you're at 100%
PHP limitscPanel → MultiPHP INI EditorRaise max_execution_time to 300 and memory_limit to 256M

If core files got partly overwritten, the safest route is to reinstall core without touching your content:

wp core download --force --skip-content

That replaces WordPress core files only. Your wp-content folder and wp-config.php are left alone. Take a backup first anyway.

Prevention

  • Back up before core updates. A cPanel backup or a WP Toolkit snapshot takes a minute and saves a bad afternoon.
  • Update one thing at a time. Don't start a manual core update while auto-updates are running.
  • Keep the tab open. Let the update finish before you navigate away.
  • Raise PHP limits to sensible values so updates don't die halfway.
  • Update from the terminal with wp core update on bigger sites. It isn't tied to a browser session or web request timeouts.

Frequently Asked Questions

Is it safe to delete core_updater.lock?

Yes, as long as no update is genuinely running. It's just a timestamp row that WordPress recreates whenever it needs it. If you're not sure, wait the 15 minutes first.

Why does the message come back right after I delete the lock?

Usually an object cache is serving the old value, or a WP-Cron auto-update is re-creating it. Flush the cache and check for scheduled update events with wp cron event list.

Will this lose my posts or settings?

No. Deleting one row from wp_options doesn't touch your content, users or plugin settings.

My table prefix isn't wp_. How do I find it?

Open wp-config.php and look for the $table_prefix line. Use that value in front of options in the SQL query.

Plugin updates fail with the same message. Is it the same fix?

Plugin and theme updates use different checks, so that's usually a permissions or disk space problem instead. See our post on "Update failed: could not create directory".