Another update in progress
There is no other update. There's a lock that outlived one.
'Another update is currently in progress' is WordPress's politeness protocol: a database lock prevents two updates from colliding. When an update dies, the lock survives it — and keeps reporting a ghost update, forever, to anyone who tries.
Same-day diagnosis. Flat quote before any fix.
What’s actually happening
Before core updates, WordPress writes a lock entry (core_updater.lock) to the database — a note saying 'update running, everyone else wait.' The completing update deletes it. A crashing update doesn't. The message you're seeing is that orphaned note, faithfully guarding a process that no longer exists.
By design the lock self-expires — fifteen minutes — so patience genuinely is the first-line fix. A message that survives well past that window means either the expiry check itself is misfiring (object caches are a known accomplice, serving the stale lock beyond its death), or repeated update attempts keep re-laying fresh locks atop the mess.
The usual causes, ranked
After twenty-seven years of these calls, the odds are well mapped. Start at the top.
An update crashed and orphaned its lock
The overwhelming cause: timeout, memory, or connection death mid-update — the lock outlives its owner.
An object cache serving the stale lock
Redis or Memcached returning the cached lock after the database expired it — the fifteen-minute promise broken by the cache layer.
Colliding update attempts
Auto-updates and a human clicking simultaneously — one legitimate lock, one confused message, occasionally one real mess.
What you can safely try first
Nothing below can make things worse — that’s the selection criterion. Anything riskier belongs in professional hands, on a backup.
- 1
Wait the fifteen minutes — genuinely
The lock self-expires. Set a timer, make coffee, try again. A shocking share of these resolve exactly this way, and no other 'fix' is this safe.
- 2
Check whether the update actually completed
Dashboard → Updates: sometimes the update finished and only the message wedged. If versions look current, the lock is all that's stale.
- 3
If you run an object cache, flush it after the wait
Redis/Memcached holding the dead lock is the classic over-stayer. A cache flush (from your host panel, safely) evicts the ghost.
Stop and call when…
- The lock outlives the wait and a cache flush — database-side removal is a two-minute job done carefully, not a guess
- The underlying update actually failed — the lock is the symptom; the half-flight update is the patient
- This recurs every update cycle — the timeouts causing it are the real diagnosis
From there it’s our job: same-day look, flat quote, and the $229 flat repair covers most cases of exactly this.
Single Error Fix — buy it now, skip the hunt.
One error, hunted down and fixed — 500s, white screens, redirect loops, broken pages.
Covers one specific error or broken behavior on one site. Diagnosis, the fix, and a plain-English note on what happened. If we can't fix it, you get a full refund.
Questions we hear a lot.
Can I just delete the lock from the database?
That is the textbook fix — one option row removed — and it's genuinely simple for someone comfortable in the database, genuinely hazardous for someone guessing at wp_options for the first time. If that sentence described a foreign country, the $229 flat fix does it safely and checks the update that died underneath.
Why does this keep happening to my site?
Recurring locks mean recurring update crashes — usually hosting timeouts on a stack too heavy for its tier. The lock is the smoke; the failing updates are the fire. Fix the update reliability and the ghost stops appearing.
Is anything actually broken while the lock is stuck?
The site runs fine — the lock only blocks new updates. The risk is the queue: security patches wait behind the ghost. An afternoon's delay is nothing; a forgotten week of blocked updates is how vulnerabilities age in.
Related symptoms & help
Errors travel in packs. If this one visited, check its friends.
Evict the ghost. Check what it was guarding.
Send the symptom, get a same-day look and a flat quote from the developer who's fixed this exact thing more times than either of us can count.