WordPress auto-updates in the middle of Halloween traffic: how to see exactly what changed

Many shops run Halloween campaigns in the last week of October. Traffic goes up and the margin for error shrinks. Meanwhile WordPress keeps updating itself in the background without anyone clicking a button. Usually that's fine. When it isn't, the failure often shows up first for a customer at checkout, hours after the update. By then the link between the two is hard to see.

This article is about that link. What updates automatically, when does it run, which failures show up first under load, and how do you prove which change lines up with the error?

What actually updates automatically?

Start by finding out what is switched on. It varies between sites, and sometimes between hosts.

• Minor core releases (for example 6.x.1 to 6.x.2) install automatically by default. The WP_AUTO_UPDATE_CORE constant controls this.
• Translations update automatically by default.
• Plugins and themes only update automatically if this has been enabled for each one. The auto_update_plugin and auto_update_theme filters or the host can also control it.
• Everything is switched off if AUTOMATIC_UPDATER_DISABLED is set to true.

WP-CLI shows you where things stand in seconds:

• wp plugin auto-updates status --all lists which plugins update themselves.
• wp theme auto-updates status --all does the same for themes.
• wp config get WP_AUTO_UPDATE_CORE returns an error if the constant isn't defined, which means the default applies.
• grep -rn "auto_update_" wp-content/mu-plugins/ finds filters that override what the admin screen says.

Why this matters: a client who says "we never auto-update" may well have a host that does it for them. Don't go by what anyone assumes. Check.

When do updates run?

Background updates run through WP-Cron. The wp_version_check, wp_update_plugins, wp_update_themes and wp_maybe_auto_update events are normally scheduled twice a day. Page views trigger WP-Cron, so the exact time depends on when traffic arrives. You can see the next run with:

wp cron event list --fields=hook,next_run_relative,recurrence

During a campaign, that means an update can run in the middle of the day, right in the rush. If the site uses system cron instead of WP-Cron, the server's schedule sets the timing, so check the crontab as well.

While an update is running, the auto_updater.lock option exists. If wp option get auto_updater.lock returns a value, a run is in progress or was recently interrupted.

Failure patterns that show up first under higher traffic

Maintenance mode and 503s

During a core update, WordPress writes a .maintenance file to the web root. Visitors then get HTTP 503 with Retry-After: 600. WordPress ignores the file once it is older than ten minutes, so an interrupted maintenance mode rarely lasts longer than that. But ten minutes of 503s at a campaign peak is ten minutes without sales. An interrupted update can also leave a plugin half-updated.

Fatal errors, and what the built-in rollback misses

Since WordPress 6.6, core makes a loopback request after a plugin auto-update. If it finds a fatal PHP error, it restores the previous version. That is a useful safety net, but it has clear limits. It does not catch:

• JavaScript errors that only hit the checkout or the cart.
• Errors that only happen for logged-in customers, specific payment flows or certain product types.
• Warnings and deprecation notices that fill the error log and slow the site down.
• Changed templates or behaviour that produce no error at all, just the wrong result.

Problems that scale with load

An update can change a database query so that it takes 300 ms instead of 30 ms. At low traffic you barely notice. At campaign traffic, PHP workers run out and you get 502 or 504 errors. Many caching plugins also purge the cache after an update. A cold cache during a traffic peak is a common route to timeouts.

The notification nobody reads

After automatic updates, WordPress sends an email to the site's admin address. Check where it goes with wp option get admin_email. On many client sites it lands in an inbox that nobody watches.

How Ravnsight Detective records what changed

With background updates, the error itself is rarely the hard part. The hard part is that nobody knows what changed or when. Ravnsight Detective is a free WordPress plugin. It records changes (plugin, theme and core updates) on the same timeline as PHP errors, JavaScript errors, performance, cron and WooCommerce events.

Here is a simplified example of how such a timeline reads:

• 13:12 Change: a gift-card plugin was updated automatically.
• 13:14 The first PHP warnings from the same plugin appear.
• 13:40 JavaScript errors on the checkout page.
• 13:45 Completed WooCommerce orders drop.

Detective puts these events in order and names a likely cause. It shows the evidence that supports the conclusion and the evidence that contradicts it, with a confidence level: LOW, MEDIUM, HIGH or CONFIRMED. In the example above, the update is strongly correlated with the errors. It only becomes confirmed after an isolation test. The test disables the suspected plugin for the administrator's own session only, so visitors are never affected. The level is set to CONFIRMED only if the error goes away and comes back when the plugin is switched on again.

Detective observes and diagnoses. It does not roll back versions or change anything on its own. The plugin makes no external requests unless you opt in.

From the outside: see it before customers do

The timeline from inside the site explains why. External monitoring tells you when. During a campaign, three checks matter most:

• Keyword check on a page that has to work, for example that the text on the buy button is present. This also catches pages that return 200 but show the wrong content.
• Synthetic flow (Pro) that adds a product to the cart and goes to checkout in a real browser.
• Homepage snapshot with JavaScript-error capture, which shows errors a plain HTTP check never sees.

Checks run every minute from Germany, and a failed result is confirmed from Finland or Sweden before anyone is alerted. So a short maintenance window that is already over by the time of confirmation won't page you. That's by design. The change still sits on the Detective timeline.

Before the campaign: a short checklist

1. Run wp plugin list --fields=name,version,auto_update > pre-campaign.txt and keep the file. That gives you a baseline to compare against.
2. Decide on purpose which plugins may auto-update during campaign week. Security fixes are a reason to keep core updates on. A payment plugin the campaign depends on is a reason to update it by hand, while someone watches.
3. Point the admin email at an inbox someone actually reads, or forward the notifications.
4. Add a keyword check and, if you can, a synthetic checkout flow at least a week before the campaign, so you know what normal looks like.
5. Install Detective before the campaign starts. A timeline starts recording on the day you install it. It can't look back in time.

If you'd rather update under control than let it happen in the background, Pro offers supervised updates with a rollback point and on-site backup. Even there, you decide when an update runs.