Sync stuck or “pending” forever

A sync that should take seconds and instead sits at pending for minutes is one of the more confusing failure modes — the dashboard says “working”, the site is alive, nothing is happening. Here’s the decision tree.

Quick diagnosis

Open the site detail page → Activity → Latest sync job. Look at:

• Status — pending, running, failed, or completed
• Started at — how long ago?
• Sections — which parts of the sync are queued

If the job is in pending for more than 60 seconds, something is wrong. Healthy pending lifetime is under 5 seconds.

Common causes (in order of likelihood)

1. WordPress site is unreachable (~50% of cases). The site went offline between when you triggered the sync and when the worker picked it up. Check Site → Health → Last heartbeat — if it’s red or older than 15 minutes, the site is offline. Restart the WP host, then click Retry sync.

2. WP-Cron is disabled and no traffic is hitting the site (~20%). Hubbee’s plugin polls every 30-60 seconds via WP-Cron. If WP-Cron is disabled (define('DISABLE_WP_CRON', true) without an alternative) and no human traffic hits the site, the plugin never picks up the job. Fix:

• Add a system cron job: * * * * * curl https://your-site.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1
• Or remove DISABLE_WP_CRON from wp-config.php
• Or visit any page on the site once — that triggers WP-Cron immediately

3. Job-worker capacity exhausted at scale (~10%). During a high-volume Hubbee event (AppSumo launch day, bulk-update on many sites), the worker queue can back up. Workers run with MAX_CONCURRENT_HTTP = 80. If the dashboard shows hundreds of jobs in pending across many sites simultaneously, your job will get picked up — just wait. The 99th-percentile wait time is under 5 minutes.

4. Stale command pinning a sync (~10%). A previous command that failed silently can leave a sync section in running indefinitely. Activity → Commands → filter status: running, older than 60 minutes — if any rows appear, those are stuck. Click each → Force cancel. Then trigger a fresh sync.

5. Plugin version too old (~5%). The job worker tracks the minimum plugin version it can talk to. If your plugin is older than that minimum, the job sits in pending because the worker won’t deliver work to an incompatible plugin. WP-Admin → Plugins → Hubbee → Update Now. The site re-handshakes within 60 seconds of the update.

6. Network glitch on Hubbee side (rare). Edge function timeouts, transient Supabase errors, regional outages. Check our Status page — if anything is red, sit tight; the worker retries automatically once the dependency is back.

Force-cancel a stuck job

If a job has been pending more than 15 minutes and the causes above don’t apply:

1. Site detail → Activity → Sync jobs
2. Find the stuck job row
3. Three-dot menu → Force cancel

The job moves to status cancelled. You can trigger a fresh sync immediately — the new job is independent.

Force-cancel is safe: WordPress on the other side just doesn’t get the cancelled command at all (it was never delivered). No half-applied state.

Self-test

WP-Admin → Hubbee → Diagnostics → Self-Test runs the same probes as the onboarding diagnostic plus a “can-I-claim-a-job” check. Pin the result if you contact support — we can map the failure precisely.

Prevent it from happening again

• Enable system cron instead of WP-Cron (the most common avoidable cause)
• Keep the Hubbee plugin updated — auto-update via WP-Admin is reliable
• Keep your hosting environment in a region near your team (latency-related timeouts shrink)
• For staging sites that you don’t visit often: schedule a uptime ping every 5 minutes via UptimeRobot / Better Stack / similar; that keeps WP-Cron firing