When WordPress says another update is currently in progress, do not immediately delete a database option. First confirm whether a core update is still running through the dashboard, host, scheduled automation, or another administrator. Removing a valid lock can let two update processes modify the same installation.
Identify the active update owner
Record the message, time, site URL, and action that triggered it. Check open administration tabs and ask anyone responsible for deployments whether an update was started. Review the hosting control panel's update history and available process or error logs.
A working public homepage does not prove the updater has finished. Conversely, a maintenance page is a different symptom. The maintenance-mode guide covers that public response; removing its file is not a substitute for understanding the core update lock.
Read the lock in the right installation
A developer with WP-CLI can inspect the core updater option without changing it:
wp option get core_updater.lock
Run this in the correct WordPress path and site context. The value is a timestamp, not an instruction to delete it. If the option does not exist, stop following a generic lock-removal recipe and inspect the actual process producing the message.
WordPress's core updater uses a lock with a 15-minute release timeout in the documented implementation. That does not guarantee every host job ends in 15 minutes. Slow I/O, package downloads, or a separate deployment system need their own investigation.
Who started the update?: Check host jobs and administrator activity. Is anything writing?: Resolve uncertainty before another attempt. Is the lock stale?: Retain evidence and a recoverable backup. Did the retry finish?: Verify version and business workflows. Explanatory checklist, not a customer test result.
Separate an old lock from a stalled update
Compare the timestamp with update logs and current activity. Ask the host to confirm that no updater is writing files when you cannot inspect processes yourself. Check free space and errors before starting another attempt; an underlying failure can simply recreate the problem.
If the update is active, let its responsible system finish or use that system's supported recovery procedure. If files are partially updated, preserve logs and prepare a controlled recovery rather than layering another automatic update over unknown state.
Remove a stale lock only with safeguards
Take a recoverable database and file backup. Confirm the target site, record the old lock value, and establish that no update is running. Only then can an authorized administrator remove that specific stale option through WP-CLI:
wp option delete core_updater.lock
This is a production write when run against production. Do not delete unrelated options, force database table names, or repeatedly clear a lock as a scheduled workaround. Coordinate a single retry with the person or system that owns updates.
Verify completion, not just an unlocked button
Confirm the installed core version, dashboard update status, and absence of new PHP errors. Test a public page, editor save, login, and the site's important form or checkout. Keep any incomplete database-upgrade prompt in scope until it is resolved through the supported workflow.
If the lock immediately returns with another failure, retain the earliest error and investigate storage or filesystem permissions. HandL WP can investigate a stalled update without treating lock deletion as the whole repair.
References: Core updater implementation and upgrader locking.
References reviewed October 2, 2026. Examples are explanatory; production changes require an appropriate backup and authorized access.