Most WordPress updates finish in a few seconds. When one drags on for minutes, or hangs on “Updating…” indefinitely with a spinning icon and no error, something specific is wrong, it’s rarely just “WordPress being slow” as a vague, unexplainable general condition. The list below covers what’s actually happening in each case and, more usefully, how to tell which one applies to you rather than working through every fix blind.
Minor Updates vs. Major Updates: Different Processes Entirely
Worth separating first, because they behave differently. Minor point releases (5.9.1 to 5.9.2, for instance) are usually applied automatically in the background via WordPress core’s built-in auto-update system, no visible progress bar, no admin interaction, they just happen. Major version updates (5.9 to 6.0) are typically manual, triggered from the Updates screen, and involve a more visible multi-step process: downloading the new core package, putting the site into maintenance mode, replacing core files, running any necessary database migrations, then taking the site back out of maintenance mode. If your “slow update” is actually a major version jump, expect it to take longer than a routine point release by nature, that’s not a malfunction on its own.
1. Server Resources, Actually Measured Rather Than Assumed
Shared hosting with tightly capped CPU and memory allocations genuinely does slow down file operations, particularly when a hosting provider throttles a site that briefly spikes above its allotted resources during the update process. Rather than assuming this is the problem, check your host’s resource usage panel (most shared and managed hosts provide one) during an update attempt, if CPU or memory is pegged at 100% the whole time, that’s your answer. If you don’t have visibility into that, a rough proxy is trying the same update on a local environment (Local by Flywheel, or a staging copy on a different host) and comparing how long it takes there.
Fix: If resource caps are confirmed as the bottleneck, either a higher hosting tier or a host built specifically around WordPress workloads (which typically allocate resources differently than generic shared hosting) resolves it directly. This is worth confirming before spending money on it though, plenty of “slow update” cases have nothing to do with server tier at all.
2. WP_MEMORY_LIMIT and PHP’s max_execution_time
A site with a large number of active plugins, or a plugin doing heavy work during its update routine (running a database migration on activation, for instance), can hit PHP’s memory limit or execution time cap mid-update, which either causes a visible timeout error or, worse, a silent partial failure where the update process just seems to hang. WordPress’s default WP_MEMORY_LIMIT is often lower than what a plugin-heavy site actually needs.
Fix: Add to wp-config.php, above the line that says “That’s all, stop editing”:
define( 'WP_MEMORY_LIMIT', '256M' );If updates are timing out specifically (not just slow, but erroring out partway), check your host’s PHP max_execution_time setting too, many hosts default this to 30 or 60 seconds, which is fine for normal page loads but can be genuinely too short for a database-heavy plugin update on a large site. This usually needs adjusting at the server or hosting panel level rather than through wp-config, since it’s a PHP-level setting, not a WordPress one.
3. A Stuck Maintenance Mode Lock
This is one of the more common causes of what looks like a hung update: WordPress creates a .maintenance file in your site’s root directory the moment an update begins, and deletes it automatically when the update finishes. If the update process gets interrupted, a connection drop, a server timeout, a manual page close, that file can be left behind, and WordPress will keep showing “Briefly unavailable for scheduled maintenance” indefinitely even though nothing is actually still running.
Fix: Connect via FTP or your host’s file manager, navigate to the site’s root directory, and delete the .maintenance file directly. This is safe to do once you’ve confirmed the update genuinely isn’t progressing (give it a reasonable few minutes first for a large site), and it resolves the vast majority of “stuck on updating” reports that aren’t actually still processing anything at all. If this keeps happening on the same site repeatedly, it’s usually a sign of an unstable connection between your browser and the server rather than a one-off fluke, worth investigating the underlying network reliability rather than just deleting the lock file each time and moving on.
4. Large Database, Specifically During Schema Migrations
Major WordPress version updates sometimes include database schema changes, and on a site with years of accumulated content, thousands of posts, a bloated wp_options table full of orphaned autoloaded data from long-uninstalled plugins, or an unusually large wp_postmeta table, that migration step can take noticeably longer than on a fresh install, because it’s genuinely processing more rows.
Fix: A plugin like WP-Optimize or Advanced Database Cleaner can clean up post revisions, expired transients, and orphaned metadata before you run a major update, shrinking the tables WordPress needs to touch during migration. Checking your wp_options table specifically for oversized autoloaded data (a known and common performance drag, independent of updates entirely) is worth doing periodically regardless.
5. File Permission and Ownership Mismatches
WordPress needs write access to specific directories to complete an update, and a permissions or ownership mismatch (files owned by a different user than the one PHP runs as, a common issue after a manual migration or a host change) causes WordPress to silently fail to write new files, sometimes reporting a generic error, sometimes just hanging without clear feedback.
Fix: Standard WordPress file permissions are 755 for directories and 644 for files, though the correct owner (not just permission bits) matters just as much and is host-specific, your hosting provider’s support or documentation will specify the correct user:group for your specific server setup. Getting this wrong in the other direction, permissions set too loosely (777, for instance) as a lazy fix, is a genuine security risk and not something to reach for even if it makes an update briefly succeed.
6. Caching and CDN Layers Serving Stale Files
An update can complete successfully on the server while a CDN or aggressive page cache continues serving a cached version of admin pages or asset files, making it look like the update never finished or the new version isn’t taking effect. This is a display problem rather than the update itself being slow, but it’s frequently mistaken for the same thing.
Fix: Clear your caching plugin’s cache and your CDN’s edge cache after any update completes, most caching plugins (WP Rocket, W3 Total Cache, LiteSpeed Cache) have a one-click purge, and Cloudflare’s dashboard offers the same for CDN-level caching. If you consistently see this issue, some caching plugins let you exclude wp-admin from caching entirely, which avoids the problem at the source rather than requiring a manual purge every time.
7. Outdated PHP Actually Slowing Everything Down
Running an old PHP version (7.4 or earlier, both long past their end-of-life support windows) doesn’t just risk incompatibility, it’s measurably slower across the board, PHP 8.x brought real performance improvements over 7.x in benchmarks that show up in ordinary WordPress operations, updates included. This is worth checking regardless of whether it’s your specific bottleneck, since it affects your site’s baseline performance far beyond just how updates run.
Fix: Most hosting control panels (cPanel, Plesk, or a managed host’s custom dashboard) let you change the active PHP version with a dropdown, no code changes required on your end. Test on staging first if you’re not confident every plugin and the theme are compatible with a newer PHP version, an incompatibility here is a real possibility on an older, unmaintained site.
8. Security Plugin Interference During the Update Process
Some security plugins actively monitor file changes in real time and can slow down or, in rare misconfigurations, actively interfere with legitimate file writes during a core update, mistaking WordPress’s own update process for suspicious activity. This is uncommon with well-maintained plugins like Wordfence or Sucuri under normal settings, but aggressive custom firewall rules or a plugin in an unusual configuration state can genuinely cause this.
Fix: If you suspect this, temporarily disable the security plugin, run the update, then reactivate it immediately afterward rather than leaving the site unprotected any longer than necessary. This should be a diagnostic step to confirm the cause, not a standing practice, running updates with security tooling permanently disabled defeats the purpose of having it.
9. WP-Cron Reliability, and Why the Admin UI Isn’t Always the Bottleneck
WordPress’s default cron system, WP-Cron, doesn’t run on a real, independent schedule the way a server-level cron job does, it fires when a visitor loads a page, which means on a low-traffic site, scheduled tasks (including some background update-related processes) can be delayed simply because nobody’s visited the site recently enough to trigger the check. This is a frequently overlooked cause of things that “should have updated automatically” but didn’t seem to.
Fix: Disable WP-Cron’s visitor-triggered behavior (define('DISABLE_WP_CRON', true); in wp-config.php) and set up a real server-level cron job hitting wp-cron.php on a fixed schedule instead, most hosts support this directly through their control panel, and it’s a more reliable foundation generally, not just for update-adjacent tasks.
10. Running the Update via WP-CLI Instead of the Admin UI
If you have SSH access, updating via WP-CLI is often faster and gives you far clearer error output than the admin UI’s progress bar, which tends to just say “Updating…” with no detail if something goes wrong:
wp core update
wp core update-db
wp plugin update --allBeyond speed, the real advantage here is diagnostic, a WP-CLI update that fails prints the actual PHP error or timeout reason directly in your terminal, rather than leaving you guessing at what a stalled progress bar in wp-admin actually means. For anyone doing WordPress maintenance regularly, WP-CLI is worth setting up on principle, not just for slow updates specifically.
Plugin Conflicts, Diagnosed Properly Rather Than Guessed
“Deactivate everything and see if it speeds up” is the standard advice, and it works, but it’s a blunt instrument that doesn’t tell you which specific plugin is the actual cause, which matters if you need the site fully functional again quickly. A more targeted approach: deactivate plugins in batches of a few at a time rather than all at once, retry the update between batches, and narrow down from there, this finds the culprit in roughly the same number of steps as a full binary search would, without leaving the entire site non-functional the whole time you’re troubleshooting. Plugins that hook into upgrader_process_complete or run their own migration logic on update (common in page builders, WooCommerce, and membership plugins) are disproportionately likely to be the actual source of a slow or hung update, since they’re doing real work during that window rather than just sitting passively.
Internet Connection Speed: A Smaller Factor Than It Used to Be
This gets listed in a lot of older troubleshooting guides, and it mattered more when WordPress core updates were larger, uncompressed downloads over a less reliable average connection. Core update packages are compressed and reasonably small by modern standards, and most hosting connections to WordPress.org’s update servers are fast regardless of your own local connection speed, since the actual download happens server-side, your browser is mostly just polling for progress, not downloading the WordPress core files itself. This is genuinely a minor factor for most people today; if you suspect it anyway, a basic speed test rules it in or out in under a minute, but it’s rarely worth spending much troubleshooting time on before checking the more common causes above.
Server Load and the Case for Scheduling Updates Deliberately
A server under heavy simultaneous load, high organic traffic, a scheduled backup job running concurrently, another site on the same shared server spiking resource usage, competes with your update process for the same limited CPU and I/O capacity. This is largely invisible from the WordPress admin side, you just experience it as “slow,” with no obvious cause visible anywhere in wp-admin itself.
Fix: Running major updates during genuinely low-traffic windows for your specific audience (which isn’t necessarily the middle of the night if your traffic skews to a different timezone than you’d assume) reduces contention. If your host runs scheduled backups on a fixed nightly window, avoid running major updates during that same window specifically, the two processes both hitting disk I/O heavily at once compounds the slowdown for both.
Granular Auto-Update Controls Worth Configuring Properly
WordPress core has supported per-plugin and per-theme auto-updates since version 5.5, toggleable individually from the Plugins and Themes screens, not just as a single all-or-nothing setting. A reasonable default policy: enable auto-updates for plugins from vendors you trust with a solid track record of stable releases, and leave major, business-critical plugins (payment gateways, membership systems, anything a broken update would genuinely hurt) on manual update with a staging test first. This doesn’t directly address why an individual update is slow, but it does reduce how often you’re manually triggering the kind of larger, all-at-once update batch that’s most likely to surface a resource or conflict problem in the first place.
Managed Hosting’s Built-In Safety Nets
If a lot of this troubleshooting sounds like more manual intervention than you want to be doing regularly, that’s a reasonable signal that managed WordPress hosting (Kinsta, WP Engine, Flywheel, and similar) is worth the cost difference for a business-critical site specifically because it typically includes one-click staging environments and automated backups before major updates run, so a slow or failed update is something you roll back from in a couple of clicks rather than diagnosing under time pressure on a live site. It doesn’t eliminate every cause above, a plugin conflict is still a plugin conflict regardless of host, but it removes several of the server-level variables (resource caps, PHP configuration, cron reliability) from the list of things you personally need to manage.
A Reasonable Troubleshooting Order
Rather than working through every cause above sequentially and hoping one sticks, start by checking for a stuck .maintenance file (fastest to rule out), then enable WP_DEBUG_LOG temporarily and attempt the update again to capture any actual PHP errors in wp-content/debug.log rather than guessing blind, then check server resource usage during the attempt. That sequence rules out the most common and fastest-to-diagnose causes before moving into the less common ones like security plugin interference or file permission mismatches. Always test on a staging copy first when a fix involves editing wp-config.php or changing PHP versions, since a mistake in either can take a site down entirely rather than just leaving it slow.
One last thing worth internalizing: a WordPress update that consistently takes an unusually long time, even after ruling out the obvious causes above, is often a symptom of a site that’s accumulated technical debt over time rather than a one-off glitch, years of plugins installed and never removed, a bloated database nobody’s cleaned, hosting that was right-sized for the site’s traffic three years ago but not today. Treating a slow update as a prompt to do a broader maintenance pass, not just a single fix to apply once and forget, tends to prevent the same investigation from repeating itself on the next major release.
Interesting Reads:
Why Is My WordPress Site Not Showing Up On Google
How to Keep Your BuddyPress Community Safe with Content Filters