When an update fails

Updates usually succeed. When they don't, the error message in the activity log is almost always enough to fix it — but knowing what each message means shortens the feedback loop.

Step 1 — Read the error message

Click the failed update in the site's Activity log. The error field contains the exact message the connector got back from WordPress's upgrader. Common phrasings:

"Could not create directory" / "Failed to copy"

The WordPress filesystem isn't writable. On most managed hosts this means the current user doesn't own the wp-content/plugins (or themes) directory. Fix on the host side — most managed WordPress hosts have a "repair file permissions" button in their control panel — then retry.

"Destination folder already exists"

A previous update left an incomplete directory behind (e.g., yoast-seo.old). SSH in, remove the stale directory, retry. If you can't SSH, a support ticket with the site URL works.

"Download failed: 403" / "Download failed: 404"

The connector couldn't fetch the plugin ZIP from Manage GPL's download proxy. Usually transient; retry after a minute. Persistent failures usually mean your subscription lapsed mid-update (the signed download token becomes invalid if entitlement drops). Check Billing.

"Plugin could not be activated because it triggered a fatal error"

The new version has a PHP error that would have taken your site down. The connector's auto-heal feature deactivated the plugin before the error reached the frontend. Your site is fine. See Auto-heal: recovering from a fatal plugin error for what to do next.

"Timed out after 60 seconds"

The site took longer than a minute to respond. Usually a slow/oversubscribed host or a very large plugin. Retry once; if it keeps timing out, raise a support ticket with the plugin name and host.

Step 2 — Retry

Updates don't retry automatically. After fixing the root cause, click Update again. Every retry creates a new activity log entry, so you have a clean history of what happened.

Step 3 — Check site is still healthy

Even if the update failed, open the site's homepage in a browser and spot-check the critical pages (checkout for stores, a product page for WooCommerce, etc.). Failed updates don't usually break live sites — WordPress's upgrader is atomic — but it's worth a quick look.

Recurring failures on a specific site

If one site keeps failing updates while others succeed, the cause is almost always:

• Filesystem permissions
• A security plugin interpreting the update as an attack
• Outdated PHP (some plugins require PHP 8.1+)
• Low memory limit (memory_limit < 128M)

Open the site's Health tab to see its PHP version, memory limit, and SSL state. Most issues are visible there.

Reading the History tab

Every update — manual or scheduled — writes to the per-site History tab. A few entries you'll see for scheduled runs specifically:

• Scheduled run started — the run kicked off, with the count of items queued.
• Plugin updated / Plugin update failed — one row per item processed. Each carries a Scheduled badge so you can tell scheduled-vs-manual at a glance.
• Scheduled run complete — wraps up the run with the applied/failed totals.