WordPress Automatic Updates: How to Enable, Disable, and Control Them

WordPress can update itself. Since version 3.7 it has shipped with automatic updates for minor core releases enabled by default, and since 5.5 you can opt in to plugin and theme auto-updates from the dashboard. The system works well in practice, but most site owners do not know exactly what is being updated automatically, what is not, or how to take control of it.

This guide covers what WordPress updates on its own, how to enable major core auto-updates, how to turn auto-updates on or off for plugins and themes, how to fix the “another update is currently in progress” error that traps a site mid-upgrade, and how to weigh the convenience of auto-updates against the risk of a plugin update breaking your site.

What WordPress updates automatically by default#

Out of the box, WordPress only auto-applies minor core releases. That means:

• Yes, automatic: security patches and bug fixes within the same major version (5.6.1 → 5.6.2, 6.4.1 → 6.4.2, etc.). These are the releases that fix vulnerabilities without changing functionality.
• No, manual: major core releases (5.6 → 5.7, 6.3 → 6.4). These can introduce breaking changes, so WordPress waits for you to approve them.
• No, manual: plugins, themes, and translations – unless you explicitly enable auto-updates for them.

This default is conservative on purpose. Minor releases are tightly scoped to security and stability fixes, so the risk of an auto-applied minor breaking your site is low. Major releases and plugin/theme updates carry more risk because they can change APIs, alter database schemas, or introduce incompatibilities.

If you want to confirm what version your site is currently running before you change anything, see how to check your WordPress version.

How to enable major core auto-updates#

You have two ways to opt in to major core auto-updates: from the dashboard (since WordPress 5.6) or via wp-config.php .

Dashboard method

Go to Dashboard > Updates. Below the WordPress version line you will see one of two messages:

• “This site is automatically kept up to date with maintenance and security releases of WordPress only.” – meaning minor-only.
• “This site is automatically kept up to date with each new version of WordPress.” – meaning all releases.

Click “Enable automatic updates for all new versions of WordPress” to switch on major auto-updates, or “Switch to automatic updates for maintenance and security releases only” to switch back.

wp-config.php method

The dashboard toggle just sets an option in the database. The constant in wp-config.php always wins, so if you want a guarantee that survives a database restore or a plugin reset, set it explicitly:

define('WP_AUTO_UPDATE_CORE', true);   // major + minor
define('WP_AUTO_UPDATE_CORE', 'minor'); // minor only (default)
define('WP_AUTO_UPDATE_CORE', false);  // disable all core auto-updates

A full breakdown of every constant you might want to set lives in our wp-config.php explained guide.

Disabling auto-updates entirely ( false ) is rarely a good idea on a production WordPress site. The minor security releases are exactly the patches you want applied as fast as possible. Disable them only if you have a tightly controlled deployment pipeline that will apply them on your own schedule.

How to enable plugin auto-updates#

Since WordPress 5.5, you can toggle auto-updates on a per-plugin basis from the dashboard.

Per-plugin toggle

Go to Plugins > Installed Plugins. The rightmost column is “Automatic Updates” and each row has either an “Enable auto-updates” or “Disable auto-updates” link. Click to toggle. The setting takes effect on the next twice-daily auto-update check.

This is the safest level of granularity: you can enable auto-updates for plugins you trust (for example, the security plugin you depend on for patches) and leave it off for plugins you want to test before updating (for example, anything that touches the checkout flow on a WooCommerce store).

Enable for all plugins via wp-config

If you want every plugin auto-updated regardless of its dashboard setting, drop a filter into a must-use plugin file (or your theme’s functions.php , though MU is cleaner):

add_filter('auto_update_plugin', '__return_true');

To disable across the board:

add_filter('auto_update_plugin', '__return_false');

Filters in code override the per-plugin dashboard setting.

How to enable theme auto-updates#

Themes follow the same pattern. Go to Appearance > Themes, click on a theme, and use the “Enable auto-updates” link in the theme details panel.

To force the behavior site-wide:

add_filter('auto_update_theme', '__return_true');  // enable
add_filter('auto_update_theme', '__return_false'); // disable

For most sites, theme auto-updates are lower-risk than plugin auto-updates because the active theme changes less often and the standard WordPress themes (Twenty Twenty-Four, etc.) are well-maintained. The risk goes up if you have customizations to a parent theme – which is why you should be using a child theme. If you have edited a parent theme directly, an auto-update will overwrite your changes.

"Another update is currently in progress" - what to do#

This is the most common failure mode of the auto-update system. WordPress sets a lock in the wp_options table when it starts an update, and clears it when the update finishes. If the update is interrupted – PHP timeout, server restart, browser tab closed during a manual update – the lock is left behind and every subsequent update attempt sees it and refuses to proceed.

The error appears as: “Another update is currently in progress.”

The fix is to delete the lock. WordPress automatically clears it after 15 minutes, so the simplest fix is to wait. If you cannot wait, clear it manually using one of three methods.

Method 1: WP-CLI (cleanest)

wp option delete core_updater.lock

If the lock is for a plugin or theme update specifically, the lock options are auto_updater.lock and auto_core_update_send_email . List anything matching:

wp option list --search="*updater*"

Then delete what you do not need.

Method 2: phpMyAdmin or MySQL CLI

In your database, run:

DELETE FROM wp_options WHERE option_name = 'core_updater.lock';

If your table prefix is not wp_ , adjust accordingly. If you cannot remember your prefix, it is defined in wp-config.php .

Method 3: A small plugin

If you do not have WP-CLI access and you do not want to touch the database directly, drop a one-shot plugin into wp-content/mu-plugins/ :

<?php
delete_option('core_updater.lock');

Hit any page on the site to trigger it, then delete the file.

After clearing the lock, the next update attempt will proceed normally. If the original update was actually still running and you forced it to abort, run the update again from Dashboard > Updates to make sure it completes cleanly. If your site will not load at all after a failed update, you may be looking at the WordPress white screen of death and need to recover before retrying.

The risks of auto-updates and how to mitigate them#

Auto-updates are not free. The reason WordPress is conservative about what it auto-applies is that any update can break a site. The most common ways:

• Plugin update introduces a bug. A plugin author ships a regression and your site breaks the next time the auto-updater runs at 2 AM. You find out when you check the site in the morning.
• Plugin compatibility breaks. Plugin A updates to require a feature that plugin B has not implemented yet. Both plugins worked yesterday; today the combination throws a fatal error.
• Plugin requires a newer PHP version. The update requires PHP 8.2 and you are still on 7.4. The plugin deactivates itself or throws an error. Modern WordPress has auto-update safety checks for the version constraint, but they do not catch every case.
• Theme update overwrites customizations. As mentioned above, if you edited the parent theme, the update wipes the changes.
• Major core update breaks a plugin or theme. A new WordPress version deprecates a function your plugin uses, and the plugin breaks until the author releases a fix.

The standard advice is: test updates on a staging site first. In practice, most WordPress sites do not have a staging environment, so the realistic risk-mitigation playbook is:

1. Enable auto-updates only for plugins you trust to ship clean releases. Big plugins with active maintainers (Wordfence, Yoast, WooCommerce for the security tree) are usually safe. Small or abandoned plugins are not.
2. Keep manual updates for anything business-critical. WooCommerce stores in particular benefit from staging-tested updates because a broken checkout costs money.
3. Have a recent backup before any update. Auto or manual. If you do not have one, back up WordPress manually before changing anything.
4. Have a way to roll back fast. A backup is only useful if you can restore it within minutes when the site goes down. Know your provider’s restore process before you need it.
5. Subscribe to security advisories for the plugins you depend on. Many WordPress plugin vulnerabilities are exploited within hours of disclosure. Patch fast or auto-patch.

How Hostney handles auto-updates#

On Hostney’s managed WordPress, auto-updates are not a single on/off switch – they are four independent toggles per WordPress installation, each with its own delay window:

• Core minor – default on, applied 1 day after release.
• Core major – default off, applied 5 days after release if you opt in.
• Plugins – per-install toggle, applied 2 days after release.
• Themes – per-install toggle, applied 2 days after release.

The delay is intentional. New releases occasionally ship regressions, and a 1-to-5-day buffer lets those regressions surface in other people’s logs before they land on yours. You can shorten or extend each delay independently per installation.

Every managed update also runs inside an update window – a quiet-hours range (start time and end time) that you set per installation. If your update window is 03:00 to 05:00, that is the only time the platform will actually apply queued updates, even if a release dropped at noon. This keeps update activity off your peak-traffic hours.

Before each managed update runs, the platform takes an automatic snapshot. Restore is one click from the Snapshots tab on the WordPress management page – it queues the snapshot for restore through the platform’s restore worker, not a database file dump you have to upload. If a plugin update breaks the site, you can roll back inside a minute.

Two more pieces of the safety net:

• Staging – the WordPress page has a Staging tab that creates a clone of your live site on a subdomain. Test the update there first if it is a high-risk change (a major version bump, a WooCommerce extension, anything that touches the checkout flow).
• Vulnerability scanning – the platform tracks known CVEs against your installed core, plugin, and theme versions. The vulnerability badges in the WordPress list tell you which installations have unpatched vulnerabilities, so you know whether the right answer is “wait for the delay window” or “patch right now”.

If you want different behavior than the platform defaults – all auto-updates off, all plugin auto-updates forced on regardless of the per-install toggle – the wp-config and filter approaches above still work. Anything you set in wp-config.php overrides the platform defaults for that installation, so you can mix and match: keep managed core minor updates with their delay, but force every plugin to auto-update through a wp-config filter, for example.

Summary#

WordPress auto-updates are a useful default, not a complete patching strategy. Out of the box, only minor core releases are auto-applied. Opt in to major core auto-updates from Dashboard > Updates or via WP_AUTO_UPDATE_CORE in wp-config.php . Toggle plugin and theme auto-updates per item from the relevant admin screen, or globally with auto_update_plugin and auto_update_theme filters. If a stuck “another update is currently in progress” error blocks future updates, delete the core_updater.lock row in wp_options via WP-CLI, phpMyAdmin, or a one-shot mu-plugin.

The bigger question is which updates you trust to apply unattended. Trusted plugins, yes. Anything that touches checkout, custom integrations, or a heavily modified theme: keep manual or test on a staging site first. Always have a recent backup and a rollback plan you have practiced before you need it.

If you are running into other update-related issues, see how to fix the most common WordPress errors for a wider catalog. If you have lost access to the admin area entirely – for example because an auto-update changed something that broke the login flow – the recovery steps in locked out of WordPress admin cover the standard ways back in.