Skip to content

WordPress Automatic Background Updates: What Updates Itself, and What Doesn’t

WordPress Automatic Background Updates: What Updates Itself, and What Doesn’t

“Does WordPress update itself?” is a common question right after taking over a site’s maintenance. The honest answer is: some things do, and some things don’t. If you don’t know where the line is, you can end up assuming updates are running when they’ve quietly stopped.

This article walks through what WordPress’s automatic (background) updates cover, when they run, and where you can change the behavior. It describes general WordPress behavior, not any specific product.

Note: This is based on the behavior documented by WordPress. Defaults can change between versions, so confirm on your own site through the admin screen or WP-CLI.

What is updated automatically depends on the type

Target Default behavior
Core, minor and security releases Updated automatically
Core, major releases Not automatic (an administrator opts in)
Plugins Not automatic (can be enabled per plugin)
Themes Not automatic (can be enabled per theme)
Translation files Updated automatically

“Minor” and “major” refer to how version numbers move. Going from 6.5.2 to 6.5.3 is minor (mostly bug and security fixes). Going from 6.5 to 6.6 is major (new features).

So even a site you never configured is probably applying small core updates and translations on its own, while plugins and themes stay put until someone allows them.

When and how it runs

There is no dedicated background program. Automatic updates ride on WP-Cron, WordPress’s pseudo-cron.

  1. About twice a day, WordPress runs an update check.
  2. If anything eligible for automatic update is found, it is applied.
  3. A result email goes to the site administrator.

WP-Cron is triggered by visits to the site. A site with very little traffic may check late. If the server runs a real cron job that calls WP-Cron on a schedule, that job is what triggers the update check.

Three places to change the behavior

1. The admin screen. Plugins and themes can be switched to automatic one by one from their list pages. For core, you choose whether major releases are included.

2. Constants in wp-config.php.

// Minor core updates only
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

// Include major releases
define( 'WP_AUTO_UPDATE_CORE', true );

// No automatic core updates
define( 'WP_AUTO_UPDATE_CORE', false );

Setting AUTOMATIC_UPDATER_DISABLED to true turns off the whole automatic updater.

3. Filter hooks. Code in a theme or plugin can fine-tune the decision, for example allow_major_auto_core_updates for core or auto_update_plugin for a specific plugin. A rule like “never auto-update this one plugin” usually lives in a filter.

Checking the state with WP-CLI

# Which plugins have auto-updates enabled?
wp plugin auto-updates status --all

# Enable auto-updates for one plugin
wp plugin auto-updates enable <plugin-slug>

# Is a core update available?
wp core check-update

If you look after several sites, a list of which plugin is automatic on which site helps a lot when you’re hunting for why updates stopped.

Why automatic updates sometimes don’t run

  1. No write permission. Updating replaces files, so it stops where WordPress can’t write.
  2. The directory is under version control. Core treats a Git-managed checkout as a development environment and avoids updating it.
  3. AUTOMATIC_UPDATER_DISABLED is set, sometimes by a host or a previous maintainer and then forgotten.
  4. WP-Cron isn’t running. If cron is disabled and nothing replaces it, the check never fires.
  5. A previous update is still holding the lock. An update that failed midway can pause retries for a while.

A simple order for diagnosis: is the setting enabled, is WP-Cron running, and can WordPress write to the files.

How to think about it

Automatic updates exist to reduce incidents caused by forgotten updates. For core security fixes especially, a shorter gap between release and application is safer.

Plugin and theme updates are different: appearance or behavior may change afterward. Since WordPress 6.6, a failed plugin auto-update that causes a fatal error can be rolled back to the previous version, but layout changes or altered behavior are not something that mechanism can detect.

A common practical split:

  • Core minor updates and translations: leave automatic.
  • Small, frequently updated plugins with limited impact: consider automatic.
  • Anything that handles payments, memberships or forms: keep it manual, take a backup first, and check the pages afterward.

The choice is less about technical merit than about who can check the site after an update, and how much time they have. Even with automatic updates on, keep a habit of reading the result emails and looking at the site.

Summary

  • By default, only core minor updates and translations are automatic. Major core releases, plugins and themes require explicit opt-in.
  • It depends on WP-Cron, so low-traffic sites or sites with cron disabled may check late.
  • You can change it from the admin screen, wp-config.php constants, or filter hooks, and inspect it with WP-CLI.
  • Decide the scope together with your capacity to verify the site after updates.

Pair this with a sound backup practice such as the 3-2-1 rule so there is always a state to return to before you widen what updates itself.