What Actually Breaks When You Auto-Update WordPress

Auto-updates rarely take a WordPress site offline. Since WordPress 6.6, core detects a PHP fatal error caused by an automatic plugin update and restores the previous version by itself. The white screen scenario that made people afraid of auto-updates has largely been engineered out.

What breaks instead is quieter, and the rollback never sees it: a checkout step that stops submitting, a layout that collapses on mobile, a form that posts to nowhere, a redirect rule that silently stops firing. None of those are PHP fatal errors, so core considers the update a success, sends no email, and leaves the broken version in place. On a brochure site you find out in a week. On a store you find out from the revenue.

So the useful question is not “auto-updates: yes or no” but which categories of plugin can fail invisibly on your site, and what you run on those. Below: what WordPress updates on its own today, exactly what the 6.6 rollback catches and misses, the hosting condition that quietly disables it, and a configuration you can copy.

What WordPress updates automatically by default

Most people assume more is automatic than actually is. The defaults, per the core documentation:

Two consequences people miss. First, if nobody has touched the settings, your plugins are almost certainly not auto-updating, and the thirty plugins sitting at “update available” are a far bigger risk than auto-updates ever were. Second, the forced-security-push exception means WordPress can update a plugin on your site even with every auto-update toggle off. That is deliberate, and it is the mechanism that has shut down several mass-exploitation campaigns in hours rather than weeks.

For planning: WordPress 7.1 shipped 19 August 2026, 7.1.3 on 6 October 2026, and 7.2 is planned for 10 December 2026. Major releases are where theme and page-builder breakage clusters; minor releases almost never break anything, which is why core turns them on for you.

What the WordPress 6.6 auto-update rollback actually does

Rollback arrived in two stages. WordPress 6.3 added it for manual plugin and theme updates: before overwriting, core moves the old copy to wp-content/upgrade-temp-backup/ and restores it if the install fails. WordPress 6.6 extended it to automatic plugin updates and added the part that matters — a post-update health check.

The sequence after an automatic plugin update is:

• Core makes a loopback request to your homepage.
• If that request errors, core treats it as a PHP fatal error caused by the new version.
• The previous version is restored from the temp backup.
• An email goes to the site administration address.
• Remaining queued updates continue, and the failed plugin is retried at the next auto-update check.

Read the detection step carefully, because it defines the boundary of the whole feature. One request. To the homepage. Checked only for a PHP fatal error.

What auto-update rollback does not catch

Everything below is invisible to that check. This is the list worth putting in front of whoever decides your update policy.

Note the shape of that list: the failures core protects you from are the ones you would notice in five minutes anyway. The ones that cost money are the ones it cannot see. If your site takes payments, books appointments or captures leads, rollback is not your safety net — monitoring is. And if an update does take the site down, the triage order is the same as any other outage: work the first-hour checklist before you start changing things.

The hosting condition that silently switches rollback off

Rollback depends on a working loopback request — your server making an HTTP request to itself. Plenty of setups break that: a firewall blocking outbound requests to the site’s own IP, a staging environment behind HTTP basic auth, split-horizon DNS, or a CDN that refuses requests from origin.

Core’s behaviour when loopbacks fail is to treat the failure as a fatal error and revert the update. That is the safe default, but it has a practical consequence: on such a host, auto-updates reliably roll themselves back, appear to “not work”, and the plugin stays on the old version indefinitely while you assume it is current.

Check it before you trust any of this. Tools → Site Health will report a loopback failure directly, and Site Health also checks that the temp-backup directory is writable and that there is enough disk space to take the backup at all. If either fails, the whole rollback mechanism is decorative.

Two update blockers that look like auto-updates being broken

Before blaming auto-updates for a plugin that will not move, rule these out. Both are core working as designed.

Requires PHP. Plugins declare a minimum PHP version in their header. If your server is below it, WordPress will not offer or apply the update. A site stuck on an old PHP version quietly stops receiving updates for plugin after plugin as each raises its floor — which is how sites end up with a dozen vulnerable plugins and an owner who insists auto-updates are on.

Requires Plugins. Since WordPress 6.5, plugins can declare dependencies on other plugins. An add-on whose parent plugin is missing or deactivated will not activate, and dependency chains are a common reason an update applies but the feature it belongs to stops working.

Both of these show up as “nothing happened”, not as an error. Checking PHP version and plugin headers belongs on any monthly maintenance pass, and it is five minutes of work.

What changed on WordPress.org in 2026

The case for auto-updates got stronger this year, and almost nobody has updated their advice to reflect it.

Since 5 June 2026, plugin and theme releases submitted to WordPress.org sit in a cooldown window before being distributed through the update API — currently six hours, reduced from an initial 24. On 9 September 2026 the Plugins Team announced that releases are now scanned automatically during that window, using AI analysis together with Jetpack Scan, and scored for risk. Patterns flagged include REST endpoints missing capability checks, unprepared database queries, request-driven file operations, unsafe unserialize() calls, and obfuscated or runtime-fetched code. A release scoring above the threshold is blocked from distribution, and the committer is emailed.

The team cited the case that prompted it: on 28 July 2026 a backdoor was caught in a release of a plugin with roughly 20,000 active installs. Because the release was still in cooldown it was never distributed to a single site, and the plugin was closed 26 minutes after Wordfence raised the alert.

That is the real shift. The classic argument against auto-updates was that a compromised plugin release could push malware onto your site overnight. That path is now gated by a six-hour delay plus an automated scan. Not airtight — a subtle backdoor can still score low — but the trade-off has moved, while the risk on the other side has not: the spam injections we clean up almost always trace back to a plugin that had a fix available for weeks.

A configuration that works for most business sites

The policy that fits most sites: auto-update everything except the code that can fail invisibly. Sort plugins by what they touch, not by how popular they are.

Here is that policy as code. Put it in a must-use plugin (wp-content/mu-plugins/), not in functions.php, so a theme change cannot remove it.

<?php
/**
 * Plugin Name: Update Policy
 * Description: Auto-update everything except code that fails invisibly.
 */

// Plugins held back for manual, tested updates.
$hold = array(
    'woocommerce',
    'elementor',
    'elementor-pro',
    'contact-form-7',
    'wp-rocket',
);

add_filter( 'auto_update_plugin', function ( $update, $item ) use ( $hold ) {
    if ( isset( $item->slug ) && in_array( $item->slug, $hold, true ) ) {
        return false;
    }
    return true; // everything else updates itself
}, 10, 2 );

// Themes: never automatically.
add_filter( 'auto_update_theme', '__return_false' );

And in wp-config.php, minor core releases only — major releases get scheduled and tested:

define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Two constants worth knowing precisely: WP_AUTO_UPDATE_CORE accepts true (development, minor and major), false (none) or 'minor'. AUTOMATIC_UPDATER_DISABLED set to true kills everything — core, plugins, themes and translations, including forced security pushes. That one is almost always a mistake; if someone added it to your wp-config.php years ago, it may explain a lot.

If you are not sure which of your plugins belong in the hold list, that audit is worth an hour of someone’s time — send us your plugin list and we will mark up which ones can safely update themselves on your particular stack.

Auto-updates do not run at 2am

A detail that undermines most update-scheduling advice: WordPress has no real scheduler. WP-Cron checks the list of due tasks on each page load. A task scheduled for 2:00 PM runs on the first page load after 2:00 PM, which on a low-traffic site can be hours later — so updates fire whenever the next visitor arrives, often during business hours. During an update run core keeps maintenance mode on for the full duration of the batch, so visitors in that window see the maintenance page.

If you want updates to happen in a predictable window, disable WP-Cron’s page-load trigger and call wp-cron.php from a real system cron at a time you choose. Most managed hosts offer this in the control panel; it is a two-minute change and it is the only way the phrase “updates run overnight” becomes true.

How to know an auto-update broke something

Since core only checks one URL for one class of error, the gap has to be covered outside WordPress. The minimum that is worth having:

• Uptime monitoring on more than the homepage — include the cart, checkout, and your main conversion page. Homepage-only monitoring misses exactly what rollback misses.
• A transaction check — a scheduled synthetic run that submits your main form or completes a test order. This is the one that catches silent revenue loss.
• Visual regression snapshots on key templates, if the site runs a page builder.
• PHP error log alerting — a spike in deprecation warnings after an update is the early signal that the next core release will turn them into fatals.
• A restorable backup taken before the update window, verified by actually restoring it somewhere. An untested backup is a belief, not a backup.

So should you turn auto-updates on?

For most business sites, yes — for most of the plugins, most of the time. Leaving everything manual means relying on a human to check updates weekly, forever; in practice that lapses, and lapsed updates are the most common route into a WordPress site. Turning everything on means accepting occasional invisible breakage in the plugins that touch revenue. Neither extreme is the answer; the split in the table above is.

Two situations genuinely argue for turning plugin auto-updates off entirely: a site with modified plugin files, where every update overwrites the modifications, and a site with no monitoring at all, where nobody would notice breakage for weeks. Both of those are problems to fix rather than to design around.

Whichever way you go, the parts that make updates survivable are the same: a backup you have actually restored, monitoring that checks more than the homepage, and a staging copy for the handful of plugins updated by hand. Updates are not the risk. Updating without a way to detect what broke is.

If plugin updates on your site are currently a choice between “break something” and “leave known vulnerabilities open”, that is a maintenance process problem, not an auto-update problem. Tell us what your stack looks like and we will show you where the gap is — and a slow site is often the same problem wearing a different hat, which is why neglected plugin stacks and slow load times tend to turn up together.