Sign in Start free

← Docs  /  Updates

Scheduled updates (AutoPilot)

Updated 2026-09-07

Automatic, screenshot-verified updates on a schedule — approval-mode vs. auto-mode, the diff threshold, needs-review batches, and optional automatic rollback.

Browse documentation

What it does

An update policy puts a site's plugin, theme and core updates on a recurring schedule instead of you triggering them by hand. Every run follows the same verified pipeline: restore point → before-screenshots of the pages you chose → updates, one at a time → after-screenshots → a pixel diff against a threshold you set.

How to

  1. Go to Updates → Update policies and click Enable scheduled updates for a site.
  2. Choose approval mode (the batch waits for you to approve before it runs) or auto mode (it queues and runs on schedule without waiting).
  3. Pick the pages to screenshot for the diff — cover the pages that make you money, not just the homepage.
  4. Set the diff threshold — how much visual change is tolerated before a batch is held for review.
  5. In auto mode, optionally turn on Roll back automatically when the visual diff exceeds the threshold — see Automatic rollback below. The switch is disabled in approval mode, where you are already the one deciding.
  6. Approval-mode batches appear as an Action for you to approve; every batch's before/after screenshot pair is attached either way.

Automatic rollback

Off by default, per policy, and only meaningful in auto mode. When it is on and a batch's screenshot diff comes back over the threshold, WPClientHub restores the restore point taken right before that batch — the same one-click restore you would run yourself from the Backups tab, with the same safeguards: a safety copy of the site as it is now is taken first, the archive's checksums are verified, the database is loaded alongside the live one and the files unpacked to staging, and the switch-over is atomic. The restore runs as the system, not as a team member, and is listed on the site's Backups tab as Updates · automatic rollback.

The batch stays marked needs review throughout, with the before/after pair attached — a rollback puts the site back while you look, it does not decide for you whether the change was a real regression. In the Updates attention queue a rolled-back batch is shown distinctly ("Rolled back automatically · restore #N · 31% diff", with a link to the restore) rather than as something waiting for your approval. The updates it tried remain pending and will be proposed again on the next run.

What it will not do:

  • Roll back twice for one batch, or roll back a batch whose diff could not be measured (a missing screenshot is a reason to look, not evidence).
  • Restore a pre-update point that is missing, failed, or is no longer on the site with no verified offsite copy. The batch is held for review with the reason on it.
  • Restore a point that is still being written. The pre-update backup runs alongside the updates, so on a slow site it can still be in progress when the diff comes back; the rollback waits up to 30 minutes for it, then gives up with the reason.
  • Start beside another restore on the same site, or while another backup or update batch is running there — the same one-at-a-time rules as a manual restore.

Every rollback — completed, failed, or never started — is written to the activity log and sends the update rolled back alert (Settings → Notifications; on by default for owners, admins and techs, and available to Slack, webhook and external-email notification routes) with the site, the diff percentage, and links to the batch and the restore. If the restore itself fails, the batch stays in review with the site's reason surfaced, and the updates remain applied.

Limits & defaults

SettingDefault
Schedule checkAn hourly job finds policies due to run
Default diff threshold25% pixel change marks the batch "needs review"
Screenshot viewport1366×900, headless Chromium
Restore pointAlways taken before the pipeline runs
Automatic rollback on a failed diffOff. Turn on per policy (auto mode only) in the policy editor — restores the batch's own pre-update restore point; the batch stays "needs review" with the before/after pair attached
Rollback wait for the pre-update pointUp to 30 minutes for the pre-update backup to finish, re-checked every 30 seconds; then held for review with the reason

Troubleshooting

A batch is stuck "needs review"
Open it to see the before/after pair — decide whether the visual change is expected (content change, a slider rotating) or a real regression, then act from the Updates or Backups tab. A batch the policy already rolled back says so on its row; it stays in the queue so you can still see what changed.
Automatic rollback is on but the batch says "Rollback failed"
The row shows why: the pre-update restore point never completed or is gone from the site, another restore or backup was running, or the site refused the restore (the site's own reason is shown). The updates are still applied. Open the site's Backups tab to restore the pre-update point by hand — the same restore, just started by you.
Why does a rolled-back batch propose the same updates again?
Because the site is back on its pre-update state, so those updates are pending again. Fix or exclude the plugin that broke the layout, or switch that site to approval mode so the next batch waits for you.
I want it to update everything with zero clicks
Use auto mode — approval mode exists specifically for agencies who want a human in the loop before anything ships to a client site.