Automatic updates: turning them on, and keeping a plugin out of them
The per-site Auto update switch, what a round does and skips, the padlock exception list, the core retry ceiling, and why WP Safer pauses a site after a rollback.
Automatic updates are off on a new site and stay off until you turn them on, one site at a time. WP Safer never decides that for you — a plugin update is a change to someone's live site, and which sites can take that unattended is your call, not ours.
Turn it on for a site
- Open Sites and click the site.
- On the Details tab, find the Auto update row in the information card.
- Flip the switch. Hovering it tells you the state: "Auto update is enabled" or "Auto update is disabled".
The switch is per site, and only active sites are considered — a site you have paused in the panel, or one whose connector plugin is not answering, is left alone.
What a round actually does
WP Safer looks at your auto-update sites on a recurring schedule. For each one it:
- asks the site for its current plugin and theme list, and queues an update job for every item that has a newer version it can install;
- queues a WordPress core update only if the site is behind the latest release. A site that is ahead of the version we know about is left as it is;
- skips the site entirely for this round if it still has update jobs in the queue from the last one. Nothing is stacked on top of unfinished work.
Everything a round starts goes through the normal queue and shows up in Tasks and in Logs → Activity exactly like an update you started by hand — see Where an update goes after you click.
What is never updated automatically
- Locked plugins and themes. The padlock on the row is the exception list, and it is respected by automatic rounds and by Update all alike.
- Blocked updates. A newer version the site's WordPress or PHP is too old for is not queued; it would fail on the site every time.
- The WP Safer connector plugin. Its own version is managed from our side, not through the site's update list.
Core updates also have a ceiling: if WordPress core has been attempted three times for a site in the last twenty-four hours, that site is skipped until the window passes. A site that cannot take a core update should not be retried every hour forever.
When WP Safer stops on its own
On the paid plans, an update WP Safer runs is followed by a check on the site a few minutes later. If that check says the site is broken and the update can be put back, WP Safer puts it back — and then pauses automatic updates for that site. Otherwise the next round would install the same package, break the site again, and repeat.
The pause is visible on the site's Uptime tab as Automatic updates are paused for this site, with the date and the item involved, and it never lifts by itself. When you have dealt with the underlying problem, click Resume automatic updates. Updating by hand is not blocked while a site is paused: that is your decision, taken with your eyes open.
The whole mechanism is described in When an update breaks a site.
Before you switch it on
- Have backups running. Automatic updates are much easier to live with when there is a recent restore point behind them — see Schedule automatic backups.
- On the Free plan there is no check and no rollback after an update. The checks and the automatic put-back are paid-plan features, so on Free an unattended update is genuinely unattended.
- Lock what you have customised. A plugin you edited by hand will lose those edits on any update, automatic or not.
- Sort the blocked ones out first. If a site shows N updates blocked, automatic updates cannot fix that; the site's PHP or WordPress version has to move first.