Fixing the "database update required" loop

If WordPress keeps showing "Further steps are required to make your database fully compatible" or bounces you back to wp-admin/upgrade.php on every page load without finishing, the update process is either being blocked before it can run or it ran but couldn't write to the database. Visit https://yourdomain.com/wp-admin/upgrade.php directly and run the database update from that page. If that page loads and completes normally, you're done. If it redirects you straight back to the same notice, or throws an error mid-update, work through the causes below.

Cause 1: a caching layer is serving the old notice

This is the most common version of the loop on our stack. LiteSpeed Cache and the browser can both cache the "database update required" admin notice or an old version of a plugin page, so WordPress looks stuck even after the update finished.

• Purge the LiteSpeed Cache plugin's cache from its settings in wp-admin.
• Hard-refresh the browser (or try an incognito window) to rule out a locally cached admin page.
• If you use a WordPress caching or object-cache plugin beyond LiteSpeed Cache, purge that too. Redis object cache in particular can hold onto stale option values, including the database version flag WordPress checks.

After purging, reload wp-admin. If the notice is gone, the update actually finished and you were looking at a cached page.

Cause 2: the update can't write to the database

The updater runs a batch of ALTER TABLE and INSERT statements against your WordPress tables. If the database user doesn't have full privileges, or the connection drops mid-run, the update starts but never completes, and you get the notice again on the next load.

• Confirm the database user has All Privileges on the WordPress database: cPanel → Manage My Databases (or Database Wizard), and check the user is listed against the database with full privileges. If not, add it and grant all.
• Check your PHP error log or /wp-content/debug.log (turn on logging per fixing the WordPress white screen of death if it isn't already) for a MySQL error during the upgrade attempt. A permissions error or a dropped connection will show up there.
• If the error mentions a specific table missing or a connection failure rather than a permissions issue, treat it as a database connectivity problem and work through fixing WordPress database connection errors first, since the updater can't do anything useful until the connection itself is reliable. If the connection is dropping or you're hitting a connection limit specifically, see fixing MySQL server has gone away and connection limit errors.

If the update fails partway through and leaves tables in a mixed state, running upgrade.php again is safe. WordPress's schema updates are written to be re-run without duplicating data.

Cause 3: a plugin or custom code is intercepting the redirect

Some plugins hook into admin redirects, maintenance mode, or the admin_init action in a way that fires before WordPress finishes checking whether the database update completed. This shows up as an instant redirect back to the notice before upgrade.php even has a chance to run.

• Rename /wp-content/plugins/ to /wp-content/plugins.bak/ via FTP or the file manager, then visit wp-admin/upgrade.php directly. If it completes now, a plugin was interfering.
• Rename the folder back, then reactivate plugins one at a time from wp-admin → Plugins, checking after each one whether the loop returns. This is the same isolation method described in fixing the WordPress white screen of death, applied here to find the plugin blocking the redirect instead of one causing a blank page.
• Also check for a stray .maintenance file in your site's root directory. If a previous update or migration left one behind, WordPress thinks an update is permanently in progress. Delete it via FTP or the file manager if it's older than a few minutes and no update is actually running.

If a migration or restore triggered this

The loop is common right after restoring a backup or moving a site, because the site's WordPress core files are on one version while the imported database is on another. Confirm the core files in public_html match the version you expect (check wp-includes/version.php for $wp_version), and that you didn't import a database dump from a much older or newer install than the files you're running. Mismatched pairs are the single most common trigger for a database update that won't stick.

When to contact support

If you've purged caching, confirmed database privileges, ruled out plugins, and checked for a leftover .maintenance file, and upgrade.php still won't complete or throws a MySQL error you can't resolve, open a ticket from the portal. Include the exact error text from debug.log or the upgrade screen. A real person will review the ticket and the error details you include.