WordPress
WordPress Auto-Updates
Auto-updates keep WordPress core, plugins and themes current without you watching for release notes, and they do it safely: a full backup is taken before every update, the site is checked afterwards, and anything that breaks the site is rolled back automatically.
Where Auto-Updates Live
Open Websites, click the site, open the WordPress menu in the site tab strip, and choose Updates. The page is titled Auto-updates.
The tab appears on WordPress and WooCommerce sites. If the site's hosting plan does not include the feature, the page shows an upgrade banner instead of the controls.

How a Managed Update Works
The sequence for every update, scheduled or manual, is the same:
- Back up. A full backup of the site is taken immediately before anything changes. If the backup fails, the run is skipped rather than proceeding without a safety net.
- Apply. The update is installed.
- Verify. The site is fetched over HTTP and the response checked.
- Watch. The run is held in an observation window for half an hour, during which the site is watched for errors and uptime incidents.
- Confirm or roll back. If everything is healthy at the end of the window, the run is marked Applied. If the site is returning errors, the pre-update backup is restored automatically and the run is marked Rolled back.
That observation window is why you will see a run sitting at Applied (watching) for a while. It is not stuck. It is the period in which a problem that only shows up under real traffic can still trigger an automatic rollback.
Because a backup is taken before every update, auto-updates consume backup storage in proportion to how often they run. That is the trade you are making, and it is the right one: an update you cannot undo is worse than a storage bill.
Switching It On
The master control is Automatic updates, described as the master switch for this site. It starts switched off, so nothing happens until you turn it on deliberately.
Underneath sit three category switches:
| Switch | Covers |
|---|---|
| WordPress core | Core releases |
| Plugins (default) | Every plugin without a specific override |
| Themes | Installed themes |
All three default to on, so turning the master switch on gives you the full managed behaviour. Turn an individual category off if you want to handle it yourself, for example if a client contract says core upgrades are scheduled work.
Choosing the Update Window
The Quiet hours (NZ time) selectors define the daily window used for scheduled updates, and the strip underneath draws it across a 24-hour bar so you can see it at a glance. The default is the small hours, from 02:00 to 05:00 New Zealand time.
A site is considered at most once per day. Runs are spread out rather than firing at the same instant for everyone, so the exact minute varies.
Pick a window that matches your actual traffic, not the clock. A New Zealand retail site is quiet at 3am; a site whose audience is in Europe is not. Look at the site's Analytics tab for the real shape of your traffic before you choose.
Per-Plugin Overrides
Not every plugin should be treated the same. In the Pending updates section, each plugin row has a selector with three choices:
- Default, which follows the Plugins switch above.
- Auto-update, which always updates this plugin regardless of the default.
- Manual only, which never updates it automatically.
Use Manual only sparingly and deliberately. The two good reasons are a plugin you have customised, and a plugin whose updates have broken the site before. A plugin left on manual is a plugin that quietly accumulates security vulnerabilities, so put a reminder in your own calendar to review it.
Use Auto-update for anything security sensitive that you want patched the moment a fix ships, regardless of what the default is set to.
Running Updates Now
Click Run updates now at the top of the page to start a run immediately, without waiting for the window. The same backup, verify and observe sequence applies, so a manual run is just as safe as a scheduled one.
The Pending updates section also has an Apply all updates now button once it has finished checking the site. Click Refresh in that section to re-check for new releases.
Only one run can be in flight at a time. If a run is already going, or is still in its observation window, a new one is refused.
Reading the Statistics and History
Five figures sit across the top of the page: Success rate, Applied, Rolled back, Failed and Last run. The one worth watching is Rolled back. A rollback is the system doing its job, but a pattern of rollbacks against the same plugin is telling you something.
Below that, Update history lists each run with:
- What was updated and its version change.
- A status: Applied, Applied (watching), Rolled back, Failed, Skipped, Running or Pending.
- Whether it was Scheduled or Manual.
If nothing has run yet, the section says so and explains that updates appear there after they run automatically or when you trigger them manually.
Rolling Back By Hand
A successful run keeps its pre-update backup, and rows that have one offer a Roll back control.
Clicking it asks you to confirm, and the wording is important: this restores your site to the pre-update backup taken just before this update, and changes made since then will be lost.
Read that literally. If the update ran overnight and your team has since published three posts and taken forty orders, rolling back discards them. Manual rollback is the right tool within minutes of a bad update and the wrong tool a day later. In that case, fix forward, or restore selectively from a more recent backup instead: see Restoring From a Backup.
The result is reported plainly: either the site came back healthy, or the HTTP status it returned instead.
When Updates Are Skipped
A run can be skipped rather than failed. The two common reasons:
- The pre-update backup failed. Nothing is updated, and you are notified. Fix the backup problem first: Taking a Backup.
- A run is already in flight or under observation. The site is left alone until the current run resolves.
Troubleshooting
The page shows an upgrade banner rather than the controls. The site's hosting plan does not include managed auto-updates. See Upgrading Your Plan.
Nothing runs even though the switch is on. Check that at least one category switch is on, that the window is not set to a zero-length range with the same start and end hour, and that no earlier run is still under observation.
A plugin keeps rolling back. The plugin is incompatible with something else on the site. Set it to Manual only, update it on a staging copy first, and fix the conflict there: see WordPress Staging Workflow.
Updates are applied but the site looks wrong rather than erroring. The health check looks for HTTP errors, and a visually broken page that still returns a 200 passes it. That is what the history and the manual rollback control are for.
Where To Go Next
- WordPress Updates for the manual update process.
- Restoring From a Backup when a rollback is not enough.
- Site Activity Log, which records every auto-update run.