Troubleshooting WooCommerce.com extension updates with code

Use these checks when WooCommerce.com extension updates are missing or fail on a WordPress site. Start with the Merchant troubleshooting guide; this Developer guide helps identify which request or scheduled task needs investigation.

Requirements before you begin

↑ Back to top

Before you begin, make sure you can check the affected site’s WordPress, WooCommerce, and WooCommerce.com Update Manager versions; connection state; sanitized server logs; and host scheduler configuration. Record the affected extension, exact action and error, and time it occurred. Test configuration changes on staging or with the host, and keep a rollback path. Never include access tokens, request signatures, or credentials in a report.

Check the Update Manager release

↑ Back to top

The Update Manager source checks in this guide use the official 1.0.3 package. Its plugin header lists WooCommerce 8.6 as the minimum, while its readme says WooCommerce 8.7 or newer and tested up to 8.7.0. The package does not confirm testing with WooCommerce 11.2. Confirm the installed version and current release guidance before applying a version-specific fix.

In the released 1.0.3 source, Update Manager filters subscription update details. It supplies the package URL when the product has an active subscription connected to the current site; otherwise it substitutes an expired-subscription package marker. The package contains no WP-Cron registration. Do not diagnose a missing update as a Manager cron failure from this evidence alone.

Identify the request that failed

↑ Back to top

WooCommerce 11.2 checks WooCommerce.com for extension update data with an outbound Helper API request from the site. Core can run its update callback in a cron, visitor, or auto-update thread. If logs show the outbound request failing, ask the host to check DNS, TLS, outbound firewall rules, HTTP status, and response timing for the WooCommerce.com request.

Local REST API routes serve separate site-management actions, including creating a marketplace order and checking the WooCommerce.com connection. A blocked local route may affect connecting a site or starting an installation, but it does not by itself show that the outbound update check failed. Review REST restrictions only when the failed action and logs point to one of those local routes. Preserve capability checks; do not allow every REST request.

/wc/v3/marketplace/create-order
/wccom-site/v3/connection/status

Check the scheduled-task configuration

↑ Back to top

Review the existing WP-Cron configuration and the host’s scheduler before changing it. The following setting disables WordPress’s page-load cron spawn when it is set to true:

define( 'DISABLE_WP_CRON', true );

If the setting is true, confirm that a system scheduler regularly requests wp-cron.php. WordPress documents this setup for sites that replace page-load spawning with a system task scheduler. Do not add a second definition or change the value to false without confirming how scheduled tasks are run. WooCommerce’s update callback has more than one execution context, so this setting alone does not identify why an update is missing.

Verify the change and recover

↑ Back to top

1. Ask the host to confirm the configured scheduler ran and, if applicable, requested wp-cron.php. Keep any working external scheduler in place.
2. Repeat the exact failed action. For an update check, use Dashboard > Updates > Check again and verify the expected extension version appears. For a connection or installation action, verify the corresponding local REST request succeeds.
3. If the problem continues, restore any test configuration change and give the host the timestamp, affected request, response status, and sanitized log lines. Do not expose credentials or private endpoints publicly.

For the supported external-scheduler setup, see WordPress Developer Resources: Hooking WP-Cron into the system task scheduler.