Diagnosing a Silent WP-Cron Failure: From Stuck Backups to a Reliable Fix

Reason (The Problem)

While setting up automated off-site backups with UpdraftPlus (connecting Google Drive as remote storage), a pattern emerged: every backup job — manual or scheduled — would reliably stall partway through, usually during the Themes or Uploads zip stage. Each stall showed the same signature in the UpdraftPlus log: a “next resumption” counter stuck at a negative number, meaning the job was waiting for WordPress to resume it and nothing was calling it back.

The root cause traced back to how WordPress handles scheduled tasks. WP-Cron isn’t a real system cron job — it’s a pseudo-cron that only fires when a visitor loads a page on the site. On low-traffic periods (like 10 PM on a Friday night watching a backup crawl), nothing was hitting the site, so WP-Cron never woke up to resume the multi-step backup process. Confirmation came two ways: WordPress’s own dashboard flagged “6 past-due actions” in Action Scheduler (used by WPForms, WP Mail SMTP, and others), and the Scheduled Actions table showed a queue that only began processing the moment the page was loaded — proof the trigger was purely visit-dependent, not time-dependent.

Making it worse: the managed Network Solutions “WordPress for Entrepreneurs” hosting package doesn’t expose a traditional cPanel or server-side cron job interface, which ruled out the standard fix of adding a real cron entry directly on the host.

Process (The Fix)

1. Diagnosed the stall pattern across multiple manual backup attempts, ruling out local machine resource contention (a background VMware VM was suspected and shut down, but the stall persisted — confirming it was server-side, not local).
2. Confirmed the root cause via WordPress’s own “scheduled tasks are overdue” warning and the Action Scheduler admin table, which showed pending WPForms/WP Mail SMTP/Action Scheduler housekeeping tasks stuck for over two days.
3. Ruled out native cron access by checking the Network Solutions hosting panel (WordPress → Website Details → SFTP Account Manager) — no cPanel-style Cron Jobs section existed on this managed tier.
4. Set up an external cron pinger using the free tier of cron-job.org: a scheduled job hitting https://ny2honolulu.com/wp-cron.php?doing_wp_cron every 15 minutes (*/15 * * * *), independent of any site visitor traffic.
5. Disabled WordPress’s self-triggered pseudo-cron by editing wp-config.php directly via SFTP:
   • Connected with sftp ftpwwlqkp@ftp-bb91820e.registeredsite.com
   • Downloaded and backed up the original file (cp wp-config.php wp-config.php.bak)
   • Added define('DISABLE_WP_CRON', true); just above the /* That's all, stop editing! */ marker
   • Re-uploaded via put wp-config.php
6. Verified the live site still loaded normally post-edit (no critical error, no white screen) before considering the fix complete.

Outcome

• Scheduled UpdraftPlus backups (Weekly Files / Daily Database, remote-synced to Google Drive) now run independently of site traffic — confirmed by an unattended overnight database backup completing successfully and emailing a report at 2:52 AM.
• WordPress’s real-time task queue is no longer visitor-dependent; Action Scheduler tasks and future backup jobs should clear on their own within their scheduled windows instead of stalling indefinitely.
• The fix required no hosting upgrade and no plugin changes — just one external free-tier cron service plus a single-line wp-config.php edit, made safe by taking a local backup before touching the live file.