Why Drupal's Automatic Updates Wasn't Running: `Unattended background updates` Is Disabled by Default

This article is co-authored with generative AI. While I have cross-checked facts against official documentation where possible, errors may remain. Please verify primary sources before making important decisions.

A red banner kept showing up in a Drupal admin UI: “A security update is available.” The site already had the Automatic Updates module installed, but no automatic update had ever applied. The naive question — “doesn’t installing the module mean updates just happen?” — turned out to have a very plain answer: the cron-time apply policy is shipped disabled, so the module is essentially idle until you turn it on. The fix is small, but the failure mode is easy to miss because the module name implies behavior that is gated behind a separate setting.

Observed state

Site version: Drupal 10.6.3. Latest at the time: 10.6.7 (a security patch within the same minor). The Automatic Updates module was already enabled, and the status report said the site was ready for automatic updates:

Cron was running, Composer was detected, readiness checks passed — and yet no automatic update had ever applied.

What the module is supposed to do

Per the Automatic Updates help text, patch-level updates within the same minor version (e.g. 10.6.3 → 10.6.7) are applied during cron. Updates that cross a minor version boundary (e.g. 10.6.x → 10.7.x) are intentionally limited to the UI flow, because crossing a minor introduces a higher risk of incompatibility with installed modules and themes.

So 10.6.3 → 10.6.7 should have been the easy case: same minor, security patch, exactly what unattended cron updates exist for.

Root cause: cron apply policy was set to “Disabled”

Opening /admin/config/automatic-updates revealed a three-way radio under Unattended background updates:

• Disabled ← this was selected
• Security updates only
• All patch releases

The module name suggests installing it is enough. It is not. What gets applied during cron is a separate, explicit opt-in. The default of “Disabled” is defensible — surprise updates running unattended are the kind of thing that will lock you out of a working site at the worst time, so requiring an opt-in is the safe call. But the failure is silent: the site simply never updates and the only feedback is the security banner that you may have started ignoring.

The note below the radios — When background updates are applied, your site will be briefly put into maintenance mode. — explains why the opt-in matters: cron-driven applies briefly take the site offline.

What I changed

1. Set the policy to Security updates only

This applies security patches automatically while leaving non-security patches for manual review. All patch releases is also available, but if you don’t have a staging environment to test against, the occasional incompatibility on a non-security patch can take the site down. For a single-server deployment, “security only” is the more conservative choice.

2. Re-run the readiness check

Saving the configuration produced this message:

Your site has not recently run an update readiness check. Rerun readiness checks now.

Automatic Updates requires a recent successful readiness check before it will apply anything. Changing the configuration invalidates the prior result, so it asks you to re-run. Following the link took a few seconds and returned:

No issues found. Your site is ready for automatic updates

Good.

3. Trigger cron

The cron interval here was set to three hours. To verify the new path I triggered cron manually from /admin/config/system/cron. As a precaution I would recommend backing up the database, web/, and vendor/ first.

4. Result

After the manual cron run, the status report showed Drupal at 10.6.7, zero errors, and “core update status: up to date.” The security banner was gone.

Aside: did 10.6.4, 10.6.5, 10.6.6 ever exist?

Watching the site jump from 10.6.3 straight to 10.6.7 raised the question of whether the intermediate versions even existed. The Drupal “Available updates” page only surfaces same-minor patches as installable update guidance for core (anything that crosses a minor needs Composer), so intermediate releases don’t appear inline.

Checking the official release index (drupal.org/project/drupal/releases) gave the full picture for the 10.6.x line:

So 10.6.4, 10.6.5, and 10.6.6 all exist — the site had simply accumulated four pending patches (three bug-fix and one security) while the auto-update path was idle, and Automatic Updates then jumped straight to the latest in one step.

The “Insecure” tag on 10.6.2 through 10.6.6 is a consequence of how Drupal labels prior releases: the security fixes in 10.6.7 are absent from every earlier 10.6.x, so all of them are marked insecure regardless of what they were originally released for. That’s also why “stopping at” an intermediate bug-fix release like 10.6.4 would buy you nothing in terms of security — you have to land on 10.6.7. The fact that the update guidance shows only the latest, and that Automatic Updates jumps straight there, is consistent with this. (Drupal 8 onward also numbers patches sequentially; the Drupal 7-era convention of even-for-bugfix / odd-for-security is gone, and there are no skipped numbers.)

Important caveat: cron-driven auto-update is “not officially supported”

Once the auto-apply succeeded, the status report grew a new warning:

Cron installs updates automatically

Enabled. This is NOT an officially supported feature of the Automatic Updates module at this time. Use at your own risk.

In other words:

• The cron-driven unattended apply is not officially supported in the contrib automatic_updates module’s own messaging
• “Use at your own risk” is the explicit framing

So unattended updates via cron, in the eyes of the module, sit somewhere close to experimental. The functionality works and is convenient, but if production behavior surprises you, you absorb the cost. For sites that matter, sensible compensating measures include:

• Make sure a backup is taken automatically right before each apply
• Keep email notifications on so failures surface immediately
• If neither feels enough, stay with the manual UI path

The warning is hidden until you turn the feature on, so if you’re considering enabling it, it’s worth knowing about up front.

That said, this “officially unsupported” wording comes from the contrib module’s own source — specifically automatic_updates.install’s hook_requirements. Drupal CMS, by contrast, treats cron-based unattended updates as the official supported path and documents it that way in configure-automatic-updates. So the position is genuinely two-sided. The site I’m working on uses contrib automatic_updates 3.1.x and surfaces the warning verbatim, but the same mechanism is presented as the standard route in Drupal CMS. The “not officially supported” line in this article reflects what the contrib module itself says about itself; it is not a verdict from the Drupal project as a whole.

The other configuration option: how unattended updates run

The settings page also offers a choice for the runner:

• By using the Automated Cron module or a request to /system/cron
  • Rides on Drupal’s normal cron path
  • Works on shared hosting, but Composer’s runtime can hit the PHP max_execution_time
• By the auto-update command-line utility
  • Runs server-side via CLI
  • Not subject to web-request timeouts and doesn’t impact user requests

If you have SSH and can install a system crontab, the CLI option is more robust under longer Composer runs. The site here is on shared hosting where setting up CLI cron is awkward, so I left it on the /system/cron path.

Things to remember

“Installing” Automatic Updates and “running” it are two different things

Enabling the module on its own automates nothing. Unattended background updates has to be set to Security updates only (or All patch releases) before anything happens during cron. If you’re stuck on “installed but doesn’t update,” /admin/config/automatic-updates is the first place to look.

A configuration change requires a fresh readiness check

The previous successful check is invalidated when you save settings. The framing is conservative — the environment may have shifted, so let me re-verify before applying anything.

Minor-version updates are out of scope

10.6.x → 10.7.x requires the UI flow (and even there it’s gated by additional configuration). The boundary is intentional: a minor introduces enough surface area that the project doesn’t want a cron job making that decision for you.

Automatic Updates is still a moving target

Automatic Updates and Package Manager originated as contrib modules and are being merged into core under the Auto Updates Initiative coordinated by the Drupal Association (Phase 1’s primary sponsor was the European Commission, with Acquia, Tag1 Consulting, Mtech, and Pantheon as partners).

As of May 2026:

• Package Manager: shipped in Drupal 11.2 (July 2025) as a hidden experimental core module; still experimental in 11.3
• Automatic Updates itself: still contrib (drupal/automatic_updates:^3)
• Drupal CMS bundles and enables Automatic Updates by default

So this is not yet a stable, shipped-in-core feature for a regular Drupal site — it’s a contrib module you install, with a partial core integration in progress for one of its dependencies. The release-by-release situation changes, so it’s worth checking the current status before committing to it.

Summary

• Automatic Updates does nothing on its own — installation is not activation
• Unattended background updates has to be explicitly set for cron-driven applies to happen
• Configuration changes require a fresh readiness check before applies will run
• Only same-minor patch updates are eligible for cron; minor-boundary updates go through the UI
• The contrib automatic_updates 3.1.x module flags cron-based unattended applies as not officially supported by its own messaging, while Drupal CMS presents them as the standard path — the position is genuinely two-sided

The path that needs to line up — install → policy → readiness check → cron — is short, but each step has to be in place. It’s a single radio button in practice, but missing it leaves the site sitting on known-vulnerable code while looking like it’s set up correctly. If you run a Drupal site, it’s worth a one-time visit to /admin/config/automatic-updates to confirm what is and isn’t enabled, and to plan your backup and notification posture around the “use at your own risk” framing.