WordPress plugin auto-updates: who turned them on? What WordPress records, and what it doesn’t

Who turned on auto-updates for a WordPress plugin?

WordPress plugin auto-updates leave no name behind. When someone clicks Enable auto-updates, WordPress saves which plugin, and nothing about who clicked or when.

We tested this on 13 Oct 2026 on a fresh test store running WordPress 7.1.3. The honest answer to “who did it?” is often “WordPress can’t tell you”. What it can tell you is whether the setting came from a click or from code, and that narrows it down fast.

Plugins that change on their own are one of the first things we look at on our WordPress care plan, because a surprise update is the usual start of a “nothing changed, but the site broke” ticket.

What changes when you click Enable auto-updates?

One row. On our fresh install there was no auto_update_plugins option at all. We clicked Enable auto-updates on Classic Editor at 12:43 UTC as a logged-in admin.

Before and after the click we took a snapshot of every option, every user meta row and every post row, leaving out transients. The two snapshots differed in exactly one place. The option auto_update_plugins now held a list with one entry, the plugin’s file path, classic-editor/classic-editor.php.

There was no user ID in it. There was no timestamp. Nothing else in the database recorded the click.

The Plugins screen changed too. The link now read “Disable auto-updates”, with “Automatic update scheduled in 12 hours” under it.

Why does a plugin say “Auto-updates enabled” with no link?

Because code turned it on, not a click. WordPress has a filter called auto_update_plugin, and anything can use it: a theme, a plugin, a host’s own must-use plugin.

We added a must-use plugin with one line in it:

add_filter( 'auto_update_plugin', '__return_true' );

After that, all four plugins on the Plugins screen read “Auto-updates enabled”. None of those cells had a link. The view links at the top showed “Auto-updates Enabled (4)” and “Must-Use (1)”.

That Must-Use count is your first clue. If the link is gone, open Plugins, Must-Use and read what is there.

Does Site Health warn you about forced auto-updates?

No. With that filter in place we ran Site Health’s plugin and theme auto-updates test. It passed, with the label “Plugin and theme auto-updates appear to be configured correctly”.

That is true from WordPress’s point of view. Auto-updates work. It just means Site Health won’t help you find out why they are on, or who decided.

What happens when the update runs?

We ran the update the way WP-Cron runs it, with Classic Editor 1.6.7 installed and 1.7.0 on offer. The run started at 12:47:37 UTC and ended at 12:47:47. Ten seconds.

Classic Editor was at 1.7.0 afterwards and still active. Nobody was asked to approve it.

An update that stops halfway can leave the site showing “Briefly unavailable for scheduled maintenance”. We tested how long WordPress keeps that page up in why WordPress gets stuck in maintenance mode, and the file to delete.

Timing depends on WP-Cron. Our fresh install scheduled its plugin update checks twice a day. On a site with few visitors those checks can run hours late, which we tested in why WP-Cron waits for a visitor before it runs scheduled jobs.

Who gets told when a plugin updates itself?

Only the admin email address. Our run sent one email, to the address in Settings, General, Administration Email Address, with the subject “[DistroCode Staging Store] Some plugins were automatically updated”.

The body named the plugin and both versions, then said: “No further action is needed on your part.” Nobody else on the team was told. If that address belongs to a developer who left, or an inbox nobody reads, the update happened in silence.

If an update does break something badly enough to cause a fatal error, a different email goes out. We covered the “technical issue” email WordPress sends after a fatal error separately.

How do you find out who turned it on?

Work through it in this order.

1. Look at the plugin’s row on the Plugins screen. A “Disable auto-updates” link means someone clicked. No link means code is forcing it.
2. If it was a click, check whether you had an activity log plugin running at the time. It is the only thing that could have recorded the user. WordPress itself did not.
3. If it is code, open Plugins, Must-Use, then search the theme and plugins for auto_update_plugin. Some hosts manage updates with their own must-use plugin or a dashboard setting, so check the host’s update settings too.
4. Read the admin inbox for “Some plugins were automatically updated”. Those emails give you dates and versions, even when nothing else does.

From then on, the fix is to make the next change visible. When we take on a site, we list every plugin that updates itself and the reason, point the update emails at an inbox someone reads, and add a log that records who changes plugin settings.

Should you turn WordPress plugin auto-updates off?

Not by default. Auto-updates get security fixes onto a site quickly, and turning them all off has its own risk.

The real question is ownership. Each plugin that updates itself should be a choice somebody made on purpose and can explain. A store’s checkout or payment plugin is a good candidate for a staging test first. A small utility plugin often is not.

What should you check today?

Open Plugins and filter by Auto-updates Enabled. For each plugin in that list, ask who chose it. Then check which address is in Settings, General, Administration Email Address.

If you can’t answer for one of them, tell us which plugins changed and we will trace where the setting comes from.