WordPress: clear “another update is currently in progress” without a plugin

Understand what WordPress is preventing

You start a WordPress core update and a message reports that another update is already in progress. This message can appear even when you see no progress bar. WordPress uses a lock to prevent two concurrent operations from replacing the same files at the same time.

The lock may correspond to a real operation: another administrator, an automatic task, or a hosting tool is still working. It may also remain after processing was interrupted. Troubleshooting means distinguishing these situations before changing anything.

This guide concerns the WordPress core update lock message. A plugin or host may use similar wording for its own mechanism. Check the screen displaying the message and the operation requested. Do not assume that every warning containing the word “update” uses the same database entry.

If visitors only see a maintenance page, that is a different symptom. The .maintenance file and the update lock have distinct functions. Removing the first does not prove that the other has disappeared or that file replacement is finished.

Approach 1: let a genuinely active operation finish

Do not restart the update in multiple tabs. Check the screen that started it and the information in the hosting panel. Look for processing still marked active or a recorded final result. A browser that has stopped displaying progress does not guarantee the server has stopped working.

Ask other administrators whether they started an intervention. If you use a centralized management service, check its history for this site. Record the start time and known result. The aim is to identify who controls the current operation and prevent a second start while the first is running.

If the host confirms that the process is still working, let it finish. If it takes unusually long, ask support to check the logs and processing state. Do not remove the lock simply because your own wait seems lengthy.

If a task needs stopping, use the mechanism provided by its manager or ask the provider to intervene. Randomly killing PHP processes can affect other requests and leave files partly replaced. After a confirmed interruption, check the installation before any new attempt.

Understand the lock interval without treating it as proof of a stopped process

In the current core update mechanism, WordPress requests a lock with a fifteen-minute duration. This interval determines whether an existing entry should still be respected when a new attempt seeks to acquire the lock. It is not a guarantee that every update finishes within fifteen minutes.

The general locking mechanism accepts other durations and defaults to one hour when none is supplied. You therefore need to examine the lock for the specific operation, not apply a universal interval to every WordPress task.

After confirming that no update is still working, allow the relevant interval to pass, then make a single new attempt. WordPress can normally take over an expired lock. You do not need to delete an entry immediately just because you found it in the database.

If the block persists, record its time and the site’s state. A future value, incorrect clock, access to the wrong database, or another locking mechanism may explain the result. A long-lasting message guides diagnosis; it does not replace checking these elements.

Prepare access and a restorable backup

Before direct intervention, identify the correct installation: domain, directory, database, and environment. A hosting account may contain the public site, a test copy, and an old migration. Removing a lock from the wrong database can leave the problem intact while modifying another site.

Check that a recent backup of files and the database exists and that you know how to restore it. A files-only backup does not protect posts, settings, or orders stored in the database. If a previous intervention has already failed, also preserve the current state to support analysis.

You can use the host’s backups, a database export, and a copy of the files. Keep exports in a private location outside the public directory. An SQL export may contain personal data and technical information that visitors must not be able to download.

Record the exact entry you will inspect and its value before any deletion. The backup protects against a handling error; it does not justify broad deletion. On an active store, restoring an entire old database would also lose recent transactions. The correction sought here remains limited to the identified lock.

Approach 2: inspect the lock with WP-CLI

If WP-CLI is available and you have authorized SSH access, change to the affected site’s directory. First check the address obtained by WordPress, then read the core lock option. These reads do not start an update.

The exact option name is core_updater.lock, including the period. Its value is a point in time expressed in seconds since the Unix epoch. It is not a user ID or process number. Keep the value and have it compared with server time if needed.

If the command cannot find the option, do not create it. Check the selected installation and the mechanism that produced the message. A database connection error means the read did not complete; it does not demonstrate the lock’s absence. On multisite, have the network administrator confirm the relevant context.

wp option get home
wp option get core_updater.lock

Remove only a lock confirmed to be abandoned

Use the following command only after confirming the operation has stopped, preparing the backup, and verifying that this entry matches the observed block. It deletes one precise option through WordPress. It does not repair files, restart an update, or remove other locks.

Read the result. If the option has already disappeared, do not look for a similarly named entry just to obtain a success message. A task may have finished between your read and intervention. Refresh the screen and check the current state before acting again.

If the lock reappears immediately, stop deleting it repeatedly and identify what recreates it. An automatic task or manager may have resumed the operation. Continually removing its lock would defeat protection against simultaneous interventions.

wp option delete core_updater.lock

Approach 3: find the entry in the database tool

Without WP-CLI, the tool supplied by the host, often phpMyAdmin, lets you inspect the database. Open it from your authenticated customer account. Identify the site’s database from its configuration without publishing the credentials it contains.

Find the options table. Its name depends on the installation’s prefix: wp_options is common, but not mandatory. On a network or in a database containing multiple copies, confirm the correct prefix and site before any change.

In the selected table, search for an exact match between option_name and core_updater.lock. Inspect the returned row and keep its value. Searching only for the word “update” would retrieve unrelated data you do not need to change.

If you prefer an SQL read, the example below selects this option alone. Replace the table name with the verified name. This read confirms the row; it deletes nothing. If there is no result, return to diagnosis rather than emptying the table.

SELECT option_id, option_name, option_value
FROM wp_options
WHERE option_name = 'core_updater.lock';

Delete the targeted row without touching other options

Once the absence of an active process and the lock’s abandoned status are confirmed, use the delete action on this row alone. Read the confirmation screen and verify the table name, option name, and number of affected rows. Do not use Empty or Drop table.

Do not select every entry ending in .lock. Automatic updates and other components may use their own protections for separate operations. A general options cleanup is not a repair of the core lock.

A direct database change does not go through the WordPress functions that manage option caches. If a persistent object cache retains an old value, have the host perform targeted invalidation for this site, or use the WP-CLI method where possible. Avoid flushing a cache shared by multiple sites without understanding its scope.

Then return to the dashboard and record the new state. If the message is unchanged, keep that result and have the read context checked. Repeating the same deletion in random databases would make the intervention riskier and harder to understand.

Check files before restarting an interrupted update

Removing the lock does not guarantee that the site is in a consistent state. If the first attempt was interrupted during copying, check the installed version and operation messages. A working homepage does not prove that all core files belong to the same version.

With WP-CLI, the version command provides a reference point, then checksum verification compares core files with WordPress.org’s references. Choose the relevant version and locale when the tool requires them. Comparing against the wrong version may produce differences without explaining the initial problem.

A successful check concerns the files examined, not plugins, database contents, or every site function. A network error that prevents downloading reference data is not proof of corruption. Do not disable certificate validation to force the check; have the connection problem corrected.

wp core version
wp core verify-checksums

Restart one update through the intended process

Once the lock is resolved and the installation examined, open Dashboard, then Updates. Check the proposed version and its expected compatibility with your environment. Start one operation and let its screen finish. Do not simultaneously start the same action from a hosting tool or terminal.

If you normally use WP-CLI, you can update core with its dedicated tool after preparation. Choose a single manager for this intervention. Force options and specific version changes are not necessary simply because you encountered a lock.

If WordPress then requests a database upgrade, follow the intended process with a current backup. Core files and database structure must remain consistent. On multisite, the scope may cover several sites; involve the network administrator.

If the new attempt fails, keep the first useful error: download refused, insufficient space, permissions, or interrupted processing. The lock may merely be a consequence of that failure. Addressing its presence alone is not enough if the same cause interrupts every update.

Understand why the lock returns

Compare failure times with hosting tasks and administrator interventions. An external manager may start an update while someone uses the dashboard button. Establish clear responsibility and avoid two operations on the same files at the same time.

Ask the provider to check resources, storage, and logs for the attempt. An execution timeout, interrupted connection, or inability to write a file needs an appropriate correction. Raising every limit or granting very broad permissions without diagnosis can create other difficulties.

If the server clock is wrong, have it corrected at system level. The display time zone chosen in WordPress does not replace that correction. Keep the lock value and observed time so support can compare them.

A plugin offering one-click lock removal does not automatically establish that the lock is abandoned. It replaces neither process verification nor analysis of the previous failure. Native tools and hosting tools are sufficient for this troubleshooting when used on the correct installation.

Check the site after success

Check the version shown in the dashboard and the absence of failure messages on the Updates screen. Review the logs or output from the tool used. Keep this completion evidence rather than treating disappearance of the lock as the sole success criterion.

Open several public pages and dashboard screens. Save a draft, check media, and test the site’s essential functions using a planned procedure. On a store, use appropriate test facilities without triggering a real payment solely for this check.

If a maintenance message remains, examine it as a separate problem after confirming the update is finished. Do not remove protective files while processing may still be using them. Also remove temporary diagnostic settings that are no longer needed.

Keep a short note recording the cause, affected lock, method used, and successful checks. It will help identify a recurring incident. Troubleshooting is complete when the update finishes normally and the site works with a consistent installation, not merely when the update button becomes available again.

Decide according to the lock read result

Before any deletion, classify your observation into one of these cases:

Keep the observation time with its time zone and the option’s raw value. A calculated age alone never confirms that a process has stopped. The native process and WP-CLI are sufficient; a free lock-removal button does not provide that missing evidence.

• The option exists and an operation is progressing in the manager: let its owner finish it or deal with its failure. The lock’s presence is consistent with the intended protection.
• The option exists, no task is working, and its timestamp is old: first check that native takeover after expiration works; targeted deletion is an intervention only on a truly abandoned lock.
• The option is absent but the message persists: confirm the installation, subsite, option cache, and exact source of the message. Do not create the lock in order to delete it.
• The timestamp appears to be in the future or the value changes between reads: have the clock or resuming task checked. Changing the time zone in Settings → General does not correct the system clock.