BackupBuddy Cron Jobs Not Executing and the Scheduler + Permission Adjustment That Restored Automated Backups

As website owners and WordPress administrators know, reliable backups are the cornerstone of any solid disaster recovery plan. Many turn to plugins like BackupBuddy for automated, scheduled backups of their WordPress files and databases. However, when those backups silently fail due to cron jobs not executing, the consequences can be devastating. This article delves into a real-world scenario where BackupBuddy’s cron jobs suddenly stopped functioning, and how a systematic review — including scheduler diagnosis and permission correction — restored the critical automation successfully.

TL;DR

Automated backups using BackupBuddy were not functioning due to failed cron job execution. By investigating the WordPress scheduled task system and diving into server file permissions, the root issues were identified. Adjusting the server’s file and directory permissions, along with verifying and triggering the WP-Cron alternatives, ultimately restored the backup automation system. Understanding both plugin-level conditions and server-level constraints proved crucial.

The Problem: BackupBuddy’s Cron Jobs Had Stopped

It started with a single, seemingly routine symptom: BackupBuddy was no longer sending completion emails for automated backups. Upon checking the plugin dashboard, a queue of scheduled backups appeared in a “Pending” state, some of them queued days ago. A red flag, perhaps. But it wasn’t immediately clear why the backups weren’t executing as scheduled.

When digging deeper, no backup log files were being generated. Manual backups worked flawlessly, so the plugin itself appeared functional. The issue was clearly limited to scheduled tasks — the WordPress cron jobs that BackupBuddy depends on. This confirmed the suspicion that cron execution was the root of the problem.

Confirming the Breakdown in WordPress Cron

WordPress uses its own pseudo-cron system (known as WP-Cron) that depends on site traffic to trigger scheduled events. If a site receives little or no visits — or if it’s behind a caching proxy — the cron system may stop functioning effectively. To verify this route, we used the following diagnostic methods:

• WP Crontrol Plugin: This plugin allows users to see all scheduled cron events and whether they are executing.
• Server Cron Logs: Examining server-level cron logs and HTTP logs helped determine if WP-Cron was triggered correctly.
• Test Scheduled Event: Manually creating a new scheduled event using WP Crontrol showed that nothing was triggering the scheduled queue.

The verdict? WP-Cron events were scheduled — they simply weren’t running. This effectively explained the halted BackupBuddy automation.

Root Causes and Discovery

The set of discoveries pointed toward two main contributing factors:

1. Low or No Traffic: The website in question was on a private staging environment, so WP-Cron wasn’t being triggered through standard web traffic.
2. File System Permission Issues: A recent server migration altered permission levels and changed ownership of some system files, leading to failed execution of custom PHP scripts that BackupBuddy uses for its cron handler.

This combination explained why scheduled jobs were appearing as “pending” — they were correctly registered but lacked the execution hook to run.

Scheduler Restoration: Implementing a Real Cron Job

Step one of the solution involved stepping away from WP-Cron in favor of a real cron job handled at the server level. This ensures cron execution is not dependent on site visitors. Here’s how we implemented it:

* * * * * wget -q -O - https://www.example.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

This cron job runs every minute on the server, calling the WordPress cron script directly. This setup dramatically improved reliability in environments with low traffic or server-side caching that interrupts the standard WP-Cron flow.

Addressing Permissions: A Hidden Bottleneck

The second issue was more technical and harder to spot — file and directory permissions. During the server migration, changes in ownership (from the site’s user to root) and overly restrictive CHMOD permissions on key WordPress directories prevented the BackupBuddy executable PHP files from running via cron.

We took the following steps to resolve this:

• Ownership Correction: Ensuring all site files were owned by the correct web server user (e.g., www-data).
• Directory and File Permissions: WordPress directories needed at least 755 permissions and files required 644, including those used directly by BackupBuddy to trigger backups (wp-content/uploads/backupbuddy_backups).

This involved running shell commands such as:

sudo chown -R www-data:www-data /var/www/html
sudo find /var/www/html -type d -exec chmod 755 {} \;
sudo find /var/www/html -type f -exec chmod 644 {} \;

After resetting ownership and permissions, the system started writing logs and running scheduled jobs again. BackupBuddy was successfully creating new backup archives as expected.

Verifying Operation: Logging and Monitoring

To ensure the system was restored and to prevent future disruptions, a few protective measures were put in place:

• BackupBuddy Logs: These were monitored after every scheduled backup to ensure timing and file completeness.
• WP Crontrol: Periodic checks were run to verify future cron jobs are being executed on time.
• Email Notifications: BackupBuddy’s alert system was reactivated so any failed backups could be investigated immediately.

We also logged every cron execution to a flat file on the server to verify timings even when email was not available. These combined efforts ensured long-term reliability.

Lessons Learned from This Debacle

This scenario teaches a number of important truths about running your own backup systems:

• Don’t solely depend on “set and forget” automation — monitor your cron events actively.
• Test your backup recovery process at least periodically, not just backup creation.
• File permission errors often remain silent — always check underlying file access when failures occur.

Conclusion: A System Reengineered and Recovered

BackupBuddy is a powerful backup solution, but it still rests upon WordPress’s infrastructure and content file systems. When cron isn’t functioning and permissions are misaligned, even the best backup plugins can quietly fail. Through direct server cron job implementation and careful permission correction, we restored full functionality to the automated backup setup. In the end, the combination of diagnostic insight, thoughtful system changes, and proactive monitoring ensured that site backups resumed — reliably and silently, just as they should.