Are your WordPress auto-updates actually running? Check now

WordPress auto-updates are on by default for minor core releases, but "on" is not the same as "running". A single line in wp-config.php, a host setting, or broken scheduled tasks can stop them without any warning on your front page. You can check all of it in about 15 minutes from the dashboard, and in less if you have WP-CLI.

Here is the fact that started this post. WordPress 7.1.3 came out on October 6, 2026 with 7 security fixes and 4 bug fixes, and the official release post says: "If you have sites that support automatic background updates, the update process will begin automatically." The key words are "sites that support". If your site quietly does not support them, the fixes are still waiting for you.

By the end of this guide you will know which version you are running, whether core, plugin and theme auto-updates can actually run, and what to change if something is blocking them.

What WordPress auto-updates actually are

An auto-update (WordPress calls it an "automatic background update") is WordPress downloading and installing a new version by itself, with no click from you. It covers four things: WordPress core, plugins, themes and translation files.

Think of it like a delivery service that drops off spare parts at your shop. The delivery only works if someone is at the door to sign for it. In WordPress, the person at the door is WP-Cron, the built-in task scheduler. If WP-Cron does not run, the parts never get installed.

Here is what happens out of the box, according to the official upgrade guide:

• Minor core releases (maintenance and security, like 7.1.2 to 7.1.3) update automatically by default.
• Since WordPress 5.6, new installations also get major core updates automatically, "unless WordPress detects a version control checkout" (a site managed with a tool like Git).
• Plugins and themes do not update automatically by default. The guide says background updates "only happen for plugins and themes in special cases," decided by the WordPress.org API, which the WordPress security team controls for critical patches.
• Since WordPress 5.5, you can turn on auto-updates plugin by plugin and theme by theme.

Why this matters: the 7.1.3 release included fixes for a stored XSS (a script an attacker saves into your site) on the Comments admin page, a second-order SQL injection in the WXR export, a DoS issue in WP_Http::make_absolute_url(), and unauthenticated disclosure of comments on private and unpublished posts. The release post says "it is recommended that you update your sites immediately." Auto-updates are how most sites get that done on time.

If you want the full story of that release and how to update by hand, read our post on checking the WordPress 7.1.3 security update.

Before you start

You do not need much, but get these ready first:

• An administrator login to the WordPress dashboard.
• Access to your files through your host's File Manager, SFTP, or SSH, so you can read wp-config.php.
• Optional: SSH access with WP-CLI (the WordPress command-line tool) installed.
• A fresh backup of your files and database, stored somewhere other than the server.
• About 15 minutes for the checks, more if you need to fix cron.
• Risk level: reading settings is zero risk. Turning on plugin auto-updates is low risk but not zero, because an update can break a page.

Heads up: the official auto-updates guide says that before you turn on plugin and theme auto-updates, "you may want to make sure you're able to rollback to a previous version of your website in case things go wrong." That means a backup you have actually tested. If you do not have one, follow our guide to back up your site in cPanel, keep an offsite copy and test a restore first. The upgrade guide puts it plainly: "Verify the backups you created are there and usable. This is essential."

Check your WordPress version and core updates

Start with the simplest question: did the latest release already install itself?

Step 1: Look at the Updates screen

Log in and go to Dashboard > Updates. This screen shows your WordPress version, any core update waiting, and any plugins or themes with new versions.

If you see that a newer WordPress version is available and it has been more than a day or two since its release, that is your first clue that background updates are not running. The release post's manual route is: go to your Dashboard, click "Updates", and then click "Update Now".

Quick tip: the same screen also shows the time until the next plugin and theme auto-update run, once you have enabled auto-updates for at least one item that has an update waiting.

Step 2: Confirm the version with WP-CLI (optional)

If you have SSH, this command prints the installed WordPress version. Run it from your site's root folder (the one that holds wp-config.php).

wp core version

You should see a single version number. At the time of writing (26 October 2026), the latest stable release is 7.1.3, so that is the number you want to see. If you see 7.1.2 or older, keep reading.

Check Site Health for update and cron problems

Site Health is WordPress's own self-test page. It runs a list of checks and flags anything that looks wrong. It is the fastest way to see whether auto-updates can work on your server.

Step 3: Open Site Health

Go to Tools > Site Health. The official auto-updates guide says auto-updates "rely on WordPress Cron tasks to actually perform the update," and tells you to check this screen "and search for any error message."

Give the page a few seconds to finish its tests. Then look through the list of results and open any item that mentions updates or scheduled events to read the details.

Step 4: Read the three results that matter

WordPress core has three Site Health tests that matter here. The labels below come straight from the WordPress source code reference.

The background updates test checks whether WordPress can run automatic core updates:

• Good: "Background updates are working"
• Problem: "Background updates are not working as expected" or "Background updates may not be working properly"

The plugin and theme test checks whether auto-updates for plugins and themes look set up correctly:

• Good: "Plugin and theme auto-updates appear to be configured correctly"
• Problem: "Your site may have problems auto-updating plugins and themes"

The scheduled events test checks whether WP-Cron is doing its job:

• Good: "Scheduled events are running"
• Problem: "A scheduled event has failed", "A scheduled event is late", or "It was not possible to check your scheduled events"

When you open a problem item, read the explanation under it. Write it down. You will match it against the troubleshooting list further down.

Why this matters: if scheduled events are late or failing, the auto-update switch can be on and still nothing will happen. The scheduler is the engine. The switch is only the key.

Turn on plugin and theme auto-updates

Core gets minor updates by default, but plugins and themes do not, so this part is up to you. Here is how to turn on auto-updates for the plugins and themes you trust. Make sure your tested backup exists before you do this.

Step 5: Enable auto-updates for plugins

Go to Plugins > Installed Plugins. Each plugin has an "Automatic update" column with a link to enable or disable auto-updates for that plugin. Click the link for each plugin you want to keep updated.

To do several at once, tick the checkboxes in the first column, choose the enable option from the bulk action selector at the top of the table, and click Apply.

What you should see afterwards: the link in the "Automatic update" column changes to a disable link for each plugin you switched on. If an update is already waiting, the time until the next scheduled run appears under the link.

Heads up: if the "Automatic update" column is missing, see the troubleshooting section. It usually means your WordPress version is too old or the feature was switched off.

Step 6: Enable auto-updates for themes

Go to Appearance > Themes and click a theme thumbnail. In the window that opens, right below the theme author, click the "Enable auto-updates" link. Themes have to be done one by one; there is no bulk option.

Quick tip: keep your active theme, its parent theme if it has one, and the latest default WordPress theme as a fallback. WordPress Site Health checks for that fallback. Remove other unused themes after confirming you do not need them, and keep every retained theme updated.

Step 7: Know when it runs and how you hear about it

The official plugin and theme auto-updates guide says: "By default WordPress runs auto-updates twice per day." So do not expect an update the same minute you flip the switch.

WordPress also sends email to the site owner when one or more plugins or themes update successfully, when one or more fail, and when some succeed and some fail. Check that the admin email under your general settings is an inbox you actually read.

Step 8: The WP-CLI way (optional)

If you manage many sites, WP-CLI is faster. The official reference describes wp plugin auto-updates simply: "Manages plugin auto-updates." It has three subcommands: enable, disable and status.

This command shows whether auto-updates are on for one plugin. Replace hello with your plugin's folder name (its slug).

wp plugin auto-updates status hello

The reference shows this output for a plugin that is not set to auto-update:

Auto-updates for plugin 'hello' are disabled.

This command turns auto-updates on for that plugin.

wp plugin auto-updates enable hello

You should see output like the official example:

Plugin auto-updates for 'hello' enabled.
Success: Enabled 1 of 1 plugin auto-updates.

To turn it off again, use the same command with disable in place of enable.

Find what might be blocking updates in wp-config.php

This is where silent problems usually hide. A developer or an old host setting may have added a constant (a fixed setting) to wp-config.php years ago, and nobody remembers it.

Step 9: Search the file for update settings

This command searches wp-config.php for the four settings that affect updates and prints each match with its line number. Run it over SSH from your site's root folder.

grep -n "AUTOMATIC_UPDATER_DISABLED\|WP_AUTO_UPDATE_CORE\|DISALLOW_FILE_MODS\|DISABLE_WP_CRON" wp-config.php

If you do not have SSH, open wp-config.php in your host's File Manager in view mode and use the browser's find feature to search for each name.

No output at all is good news: none of the blocking settings are set, and WordPress uses its defaults.

Step 10: Understand what each line does

Here is what each setting means, from the official wp-config.php documentation and the upgrade guide.

This line turns off all automatic updates, for core, plugins, themes and translations:

define( 'AUTOMATIC_UPDATER_DISABLED', true );

The upgrade guide says of minor core and translation updates that "disabling these updates is strongly discouraged." The wp-config.php docs give a fair reason to use it for a short time: it "can also be done before a major release to allow time for testing on a development or staging environment". Temporary is fine. Forgotten is not.

This line turns off all core updates, including security releases:

define( 'WP_AUTO_UPDATE_CORE', false );

This line turns on all core updates, both minor and major:

define( 'WP_AUTO_UPDATE_CORE', true );

This line is the default: minor core releases only.

define( 'WP_AUTO_UPDATE_CORE', 'minor' );

This line blocks the plugin and theme installation and update functionality, and also turns off the built-in file editor:

define( 'DISALLOW_FILE_MODS', true );

This line turns off the built-in WP-Cron trigger:

define( 'DISABLE_WP_CRON', true );

DISABLE_WP_CRON is fine, and often better, when a real server cron job runs WP-Cron for you. It is a problem only when nothing replaces it. If you want to set that up properly, follow our guide to running a real cron job and disabling WP-Cron.

Made-up example: Amina runs a small bakery site. Years ago a freelancer added DISALLOW_FILE_MODS to stop staff from installing random plugins. It worked. It also meant none of her plugins could update from the dashboard, and she never noticed, because the site looked fine. One grep command would have shown it in two seconds.

Step 11: Change a setting safely

Before you edit wp-config.php, download a copy of it to your computer. If the site breaks after your edit, upload the copy back and you are where you started.

To change a setting, edit the value or delete the whole define( ... ); line, save, and reload Dashboard > Updates. Ask whoever added the line first, if you can. Some hosts and agencies set these on purpose because they run updates for you.

How to check it worked

Do these checks after any change, and again a day later.

• Run wp core version or look at Dashboard > Updates. The version should match the latest release; at the time of writing (26 October 2026) that is 7.1.3.
• Open Tools > Site Health. You want "Background updates are working", "Plugin and theme auto-updates appear to be configured correctly" and "Scheduled events are running" to have no matching problem items.
• Run wp plugin auto-updates status with a plugin slug. For each plugin you switched on, it should no longer say auto-updates are disabled.
• Look in Dashboard > Updates for the time until the next plugin and theme auto-update run.
• Within a day or so of the next plugin release, check your inbox for the auto-update email. If a plugin you enabled has an update waiting and no email arrives after a day, go back to Site Health.
• Run the grep command again. It should print only the lines you meant to keep.

Troubleshooting

Auto-updates are switched on but nothing ever updates

Symptom: plugins show auto-updates enabled, updates are waiting on Dashboard > Updates, and days pass with no change and no email.

Likely cause: WP-Cron is not running, so the scheduled update job never starts. The official guide says auto-updates "rely on WordPress Cron tasks to actually perform the update."

Fix: open Tools > Site Health and look for scheduled event problems. If DISABLE_WP_CRON is set with no server cron job behind it, either remove the line or add a real cron job. Our guide to replacing WP-Cron with a cPanel cron job walks you through it.

Site Health says "A scheduled event has failed" or "A scheduled event is late"

Symptom: one of those two labels appears in Tools > Site Health.

Likely cause: WP-Cron is not firing often enough, or a scheduled task is erroring. The Site Health reference describes these checks as "Checks if any scheduled tasks are late" and "Checks if any scheduled tasks have been missed."

Fix: open the item and read which event it names. If it names a plugin's own task, update or disable that plugin. If many events are late, set up a real server cron job as described in the cron guide linked above, then reload Site Health after it has had time to run.

The "Automatic update" column or the theme link is missing

Symptom: the Plugins screen has no "Automatic update" column, or the theme window has no "Enable auto-updates" link.

Likely cause: the official guide gives two. Either you run a WordPress version older than 5.5, or "the feature was partially or completely deactivated by your hosting company or by a plugin."

Fix: check your version first. If you are on 5.5 or later, look for a plugin that manages updates and check its settings. Then ask your host whether they turn the feature off because they run updates themselves. If they do, ask how often and whether they cover plugins.

Plugins cannot update at all, even by hand

Symptom: no update links for plugins or themes, no option to add new plugins, and the file editor is gone.

Likely cause: DISALLOW_FILE_MODS is set to true. The docs say it will "block users being able to use the plugin and theme installation/update functionality".

Fix: if you want WordPress to manage plugin updates, remove the line or set it to false, after backing up wp-config.php. If it is there on purpose (some teams deploy only through Git), make sure someone actually runs updates through that process on a schedule.

Nothing auto-updates, not even translations

Symptom: core, plugins and translations all stay on old versions, and Site Health shows a background updates problem.

Likely cause: AUTOMATIC_UPDATER_DISABLED is set to true, or a must-use plugin uses the automatic_updater_disabled filter to do the same thing.

Fix: remove the constant if it was only meant for a test period. If it is not in wp-config.php, ask your developer or host about must-use plugins, since the upgrade guide says that is "the best place to put these filters."

Core minor updates do not install, but plugins do

Symptom: plugins update fine, yet you are stuck on an older minor release such as 7.1.2.

Likely cause: WP_AUTO_UPDATE_CORE is set to false, or your site is a version control checkout. The upgrade guide notes that WordPress looks for version control folders such as .git, .hg or .svn when it decides on automatic updates.

Fix: set WP_AUTO_UPDATE_CORE to 'minor' (the default) or remove the line. If your site lives in Git, plan to update core through your deploy process instead, and update by hand from Dashboard > Updates today.

Pro tips and when to ask for help

• Check monthly. Put a recurring reminder in your calendar to open Site Health and Dashboard > Updates. It takes two minutes.
• Turn on auto-updates for plugins that are well maintained and widely used. For a plugin that runs your shop checkout or payments, you may prefer to update by hand after a quick test on a staging copy.
• Keep the admin email current. The auto-update emails are your only alert that something failed.
• Ask your host if Site Health keeps reporting late scheduled events after you set up a real cron job, or if the auto-update controls are missing on a current WordPress version. Ask a developer if you find filters or must-use plugins you do not understand.

The one message worth forwarding

Copy and send this to whoever looks after your site:

"Hi, can you confirm that auto-updates are actually running on our WordPress site? Please check that we are on the latest release (7.1.3 at the time of writing), that Tools > Site Health shows no background update or scheduled event problems, and that wp-config.php does not set AUTOMATIC_UPDATER_DISABLED, DISALLOW_FILE_MODS, or WP_AUTO_UPDATE_CORE to false without a reason. If WP-Cron is disabled, please confirm a real server cron job replaces it. Thanks."

The takeaway: an auto-update switch only helps if the scheduler behind it runs, so check Site Health and wp-config.php today, not after the next security release.