What matters first: WordPress compares the database version stored in options with the version expected by the loaded core files. A loop means the update did not persist, the request uses another database, or code versions differ between nodes.
What this symptom actually tells you
Repeatedly clicking Update can hide a load-balanced or cache problem. The active core version, db_version option and database connection must be checked from the same request path.
Capture evidence before changing anything
- Record the core version served by the web node and WP-CLI.
- Read the db_version option from the database WordPress is actually using.
- Check whether multiple containers or servers run different core releases.
- Inspect database write errors, object cache and read-replica routing.
Most common causes
- Mixed code versions: One node expects a newer schema while another serves older files.
- Wrong database: Web and CLI point at different databases or table prefixes.
- Write failure: The schema update runs but cannot persist the new version option.
- Stale object cache: A cached db_version keeps returning after the database changed.
Safe diagnostic and repair sequence
- Take a database backup and place the site in a controlled maintenance window.
- Align every web node on the same complete core release.
- Run the database upgrade once through WP-CLI or the canonical admin route.
- Flush the relevant object cache and confirm the stored version from the active database.
How to choose between the likely causes
Do not treat Mixed code versions and Wrong database as interchangeable. One node expects a newer schema while another serves older files. By contrast, web and CLI point at different databases or table prefixes. Use two checks to separate them: Record the core version served by the web node and WP-CLI; and read the db_version option from the database WordPress is actually using. Those observations usually show whether the next safe move is to take a database backup and place the site in a controlled maintenance window or to preserve the current state and widen the investigation.
On a production WordPress site, repeat the failing request while checking a known-good page and the admin area. A fault isolated to one route calls for a narrower rollback than a failure affecting PHP, the database or every request. Record the exact timestamp, affected URL or transaction, last known good state and every change made during diagnosis. That handover is often what separates a repeatable repair from a temporary disappearance of the symptom.
What not to do
Do not manually edit db_version to dismiss the screen. The value is evidence of migrations that may not have run.
How to verify the repair
- Admin opens without returning to the update screen.
- Code and database versions match on every node.
- Core tables and critical plugin operations work after cache and service restart.
A visible symptom disappearing is not enough. Close the incident only when the original failing action, the surrounding business journey and the relevant logs all agree that the fault is gone.
WP REPAIR INCIDENT STANDARD
Reconstruct the incident before fixing it
Repeatedly clicking Update can hide a load-balanced or cache problem. The active core version, db_version option and database connection must be checked from the same request path.
- 1
Record the core version served by the web node and WP-CLI.
- 2
Read the db_version option from the database WordPress is actually using.
- 3
Check whether multiple containers or servers run different core releases.
- 4
Inspect database write errors, object cache and read-replica routing.
What must be verified
- Admin opens without returning to the update screen.
- Code and database versions match on every node.
- Core tables and critical plugin operations work after cache and service restart.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
Is it safe to just edit the db_version option directly to skip this screen?+
No. That value reflects whether required schema migrations actually ran, and editing it manually only hides the warning without completing the update. The site can then run on a data structure some plugins don't expect, causing subtler failures later.
Why does clicking 'Update WordPress Database' repeatedly not fix the loop?+
Repeated clicking treats the symptom, not the cause. If web nodes are running mismatched core versions, or if the web request and WP-CLI are pointed at different databases, the update can appear to run yet never persist correctly, so the loop returns on every admin visit.
Could an object cache be responsible for this loop even after the database was actually updated?+
Yes. A stale cached copy of the db_version value can keep returning after the real value in the database has changed, making WordPress think an update is still required. Flushing the relevant object cache and re-checking the stored version from the active database resolves this.
Does this loop always mean something is wrong with the WordPress core files?+
Not always. It can just as easily point to a wrong database connection, where the web server and CLI environment are targeting different databases or table prefixes, rather than any problem with the core code itself.