WordPress Auto-Update Broke My Site: How to Recover and Prevent It From Happening Again

The update you never asked for

WordPress has been auto-updating minor versions — security and maintenance releases — since version 3.7 in 2013. Since WordPress 5.6, it also auto-updates major versions by default. That means WordPress can upgrade itself from 6.4 to 6.5 at 3am on a Tuesday without asking your permission.

Most of the time, this works. The update downloads, installs, and your site continues running without issue. But when it does not work, you wake up to a white screen, a critical error message, or a 500 Internal Server Error. Your site is completely down. Your visitors see an error page. Your customers cannot place orders. Your contact forms are gone.

You did not choose to update. You did not have a chance to test. You did not back up first. WordPress decided it was time to update, the update failed, and now you are scrambling to fix a problem you did not create.

The worst part is the timing. Auto-updates run during off-peak hours on your server — which means the middle of the night for most site owners. Your site might have been broken for six hours before you even check your email. Six hours of lost visitors, lost orders, and lost trust. And if you do not have monitoring, you only find out when a customer tells you.

Why auto-updates break WordPress sites

WordPress core is well-tested before release. The problem is not WordPress itself — it is the interaction between the new version and everything else on your site. Your theme, your plugins, your PHP version, and your server configuration all have to be compatible with the new WordPress version. When any one of them is not, the update breaks your site.

1. Theme incompatibility with the new WordPress version

WordPress major versions can deprecate functions, change template loading behaviour, modify the block editor, or alter hooks that themes rely on. A theme that worked perfectly on WordPress 6.4 might call a function that was removed in WordPress 6.5. The result is a PHP fatal error that crashes your site.

This is especially common with older themes that have not been updated in months or years. Free themes from the WordPress repository are often abandoned by their developers. Premium themes from third-party marketplaces may lag behind WordPress releases by weeks. During that gap, your site is running a WordPress version that your theme does not support.

The critical error message appears — "There has been a critical error on this website" — or worse, a blank white screen. See our guide on WordPress critical errors and the White Screen of Death for detailed troubleshooting.

2. Plugin incompatibility

The average WordPress site has 20 to 30 plugins installed. Each plugin hooks into WordPress functions, filters, and actions. When WordPress changes the behaviour of a function that a plugin depends on, the plugin breaks. Since plugins are written by thousands of different developers with varying levels of testing rigour, incompatibilities are common during major version updates.

The specific symptoms depend on which plugin breaks and how it breaks. A plugin that handles page rendering might cause a white screen. A plugin that modifies the database might cause an "Error Establishing a Database Connection" message. A plugin that hooks into WordPress initialisation might prevent WordPress from loading at all.

WordPress does not check whether your plugins are compatible with the new version before auto-updating. It updates first, then you discover the incompatibility.

3. PHP version mismatch

New WordPress versions occasionally raise the minimum PHP version requirement. WordPress 6.5, for example, requires PHP 7.2.24 or higher. If your hosting provider is running an older PHP version, the new WordPress code contains syntax or functions that your PHP installation cannot parse.

This can also happen in reverse. Your hosting provider upgrades PHP from 8.1 to 8.3 and then WordPress auto-updates to a version that works with 8.3 but one of your plugins does not. The WordPress core runs fine, but the plugin crashes PHP and takes the whole site down with it.

The WordPress documentation on updating recommends checking your PHP version before updating. But auto-updates do not give you the chance to check. They just run.

4. File permission errors during the update process

WordPress auto-update works by downloading the new version, extracting it, and overwriting the existing files. This requires write permissions on the WordPress directory. If file permissions are too restrictive — or if the web server user does not own the WordPress files — the update can partially complete.

A partial update is the most dangerous outcome. Some files are the new version, some are the old version. WordPress cannot load correctly because it is a mix of two versions. The result is usually a fatal error or a white screen. Unlike a complete failure that leaves you with the old working version, a partial update corrupts your installation.

5. Server timeout during the update

WordPress auto-updates run as a PHP process. If the process takes too long — because the server is under heavy load, the download is slow, or the disk I/O is congested — PHP times out. The update is interrupted mid-process, leaving your WordPress installation in a half-updated state.

This is particularly common on shared hosting where PHP execution time is limited to 30 or 60 seconds. A major version update that needs to download and extract dozens of megabytes of files can exceed this limit. The .maintenance file that WordPress creates during the update remains in place, locking your site in maintenance mode until you manually delete it.

How to recover from a broken auto-update

Step 1: Check for the .maintenance file

Connect to your server via FTP or your hosting file manager. Look for a file named .maintenance in your WordPress root directory — the same directory that contains wp-config.php. If this file exists, delete it. WordPress creates this file when an update starts and removes it when the update finishes. If the update failed, the file remains and locks your site in maintenance mode.

Step 2: Restore from backup

If you have a recent backup — from UpdraftPlus, your hosting provider's backup system, or any other backup solution — restore it now. This is the fastest and safest recovery method. It reverts your entire site to the working state before the auto-update. You can then decide whether to update manually, after testing, rather than letting the auto-update try again.

Step 3: Replace WordPress core files manually

If you do not have a backup, download the previous WordPress version from the WordPress release archive. Extract the download and upload the wp-admin and wp-includes directories to your server via FTP, overwriting the existing files. Do not overwrite wp-content — that directory contains your themes, plugins, and uploads.

This replaces potentially corrupted core files with clean ones from the same version. If the break was caused by a partial update, this should fix it.

Step 4: Deactivate plugins via FTP

If replacing core files does not fix the issue, the problem is likely a plugin incompatibility. Via FTP, navigate to /wp-content/ and rename the plugins folder to plugins-disabled. This deactivates all plugins at once.

Reload your site. If it comes back, the problem is one of your plugins. Rename the folder back to plugins and then rename individual plugin folders one at a time — reloading your site after each one — to identify which plugin is incompatible with the new WordPress version.

Step 5: Switch to a default theme via FTP

If deactivating plugins does not fix the issue, your theme might be incompatible. Via FTP, navigate to /wp-content/themes/ and rename your active theme folder — for example, rename my-theme to my-theme-disabled. WordPress will fall back to the latest default theme (Twenty Twenty-Five or similar).

If the site loads with the default theme, your theme is incompatible with the new WordPress version. Contact the theme developer for an updated version, or revert to the previous WordPress version until the theme is updated.

Step 6: Check and fix PHP version

If none of the above works, check your PHP version from your hosting control panel. Compare it with the requirements of the WordPress version that was installed. If there is a mismatch, temporarily change your PHP version to one that is compatible.

How to catch broken auto-updates within 60 seconds

The recovery steps above assume you know your site is broken. The real problem with auto-updates is the gap between when the update breaks your site and when you discover it. That gap can be six hours, twelve hours, or an entire weekend.

Uptrue's HTTP monitoring closes that gap. It checks your site every 60 seconds. When an auto-update breaks your site, Uptrue detects the failure on the next check and alerts you immediately.

Step 1: Set up an HTTP monitor for your homepage

1. Sign up at uptrue.io/signup (free plan available)
2. Click Add Monitor from your dashboard
3. Select HTTP/HTTPS as the monitor type
4. Enter your homepage URL
5. Set expected status to 200
6. Set the check interval to 1 minute
7. Configure alerts — Slack, email, or Microsoft Teams

Most auto-update failures return a 500 Internal Server Error. The HTTP monitor detects the non-200 response and alerts you within 60 seconds. This is the difference between a 6-hour outage and a 10-minute outage.

Step 2: Add a keyword monitor for comprehensive detection

1. Click Add Monitor again
2. Select Keyword as the monitor type
3. Enter your homepage URL
4. Set the keyword to your site title or a phrase that always appears on your homepage
5. Set the check type to "Page must contain"
6. Set the interval to 1 minute

Some auto-update failures display the WordPress critical error message or maintenance mode page with a 200 status code. The HTTP monitor would miss these because the server technically responded successfully. The keyword monitor catches them because your normal content has been replaced by an error message.

Step 3: Monitor your wp-admin login page

1. Add another HTTP/HTTPS monitor
2. Set the URL to yourdomain.com/wp-login.php
3. Set expected status to 200
4. Set the interval to 5 minutes

If the auto-update corrupts WordPress core files, the admin login page is often the first thing that breaks. Monitoring it separately gives you early warning even if the frontend is being served from cache.

Step 4: Monitor critical inner pages

Auto-update breakage does not always affect every page. If a plugin breaks and that plugin only loads on specific pages — your WooCommerce checkout, your contact form page, your members area — those pages break while your homepage works fine. Set up monitors for:

• Homepage
• WooCommerce checkout page
• Contact page
• Any page running critical plugins
• Your highest-traffic landing page

Step 5: Configure alerts for overnight detection

Auto-updates run overnight. Your monitoring needs to reach you even when you are asleep. Configure your alerts to escalate:

• Slack — with mobile push notifications enabled
• Microsoft Teams — with urgent priority notifications
• Email — as a backup trail
• Webhook — to PagerDuty or Opsgenie for on-call rotation and phone alerts

Preventing auto-update breakage

You have two choices: disable auto-updates and manage them manually, or keep auto-updates enabled and monitor aggressively. Both approaches have trade-offs.

Option 1: Disable major version auto-updates

Add this line to your wp-config.php:

define('WP_AUTO_UPDATE_CORE', 'minor');

This keeps security and maintenance auto-updates (6.5.1, 6.5.2) but stops major version updates (6.4 to 6.5). Security updates are small and rarely break sites. Major updates are where the incompatibilities live. This is the recommended setting for most WordPress sites.

Option 2: Disable all auto-updates

define('WP_AUTO_UPDATE_CORE', false);

This stops all auto-updates, including security patches. You take full responsibility for keeping WordPress updated. This gives you complete control but requires discipline — you must apply security updates manually within hours of their release. Delaying security updates exposes your site to known vulnerabilities that attackers actively exploit.

Option 3: Test updates on staging first

The safest approach is to test every update on a staging site before applying it to production. Most managed WordPress hosts offer one-click staging environments. Clone your live site to staging, apply the update, test every critical page and function, and only then apply it to production.

This adds time to your update process but eliminates the risk of a surprise break. Combined with monitoring on your production site, you are covered from both directions.

Keep regular backups

Regardless of your auto-update strategy, maintain daily backups stored off-server. When an update breaks your site, a backup lets you restore to the working state in minutes instead of spending hours troubleshooting. Test your restore process before you need it — a backup you cannot restore from is not a backup.

Audit your plugins and theme regularly

Plugins that have not been updated in over a year are the most likely to break during a WordPress upgrade. Check the "Last updated" date for every plugin you use. If a plugin has not been updated in 12 months, find an alternative before the next WordPress major version arrives. The same applies to your theme — if the theme developer has stopped releasing updates, start planning a migration.

Stop discovering broken updates from your customers

WordPress auto-updates will continue running whether you want them to or not (unless you explicitly disable them). Every update carries the risk of an incompatibility that breaks your site. The question is not whether an auto-update will eventually cause a problem — it is whether you will find out in 60 seconds or 6 hours.

Uptrue checks your site every minute. HTTP monitoring catches 500 errors from failed updates. Keyword monitoring catches critical error messages and maintenance mode pages that return 200 status codes. You get alerted on Slack, Teams, email, or webhook before your visitors or customers notice anything wrong.

Set up monitoring before the next auto-update runs. When it breaks, you will know in under a minute.

Frequently asked questions