Quick verdict: UpdraftPlus depends on WP-Cron, WordPress's visitor-triggered fake cron, so a low-traffic or heavily-cached site can silently miss scheduled backups for days. BackupYourSite triggers backups over SSH from outside WordPress entirely, so the schedule runs regardless of traffic or caching.
UpdraftPlus is the most-installed WordPress backup plugin in the world, and for good reason — it's free, it's been around since 2013, and for a huge number of sites it works exactly as expected. But there's one structural fact about how it (and nearly every plugin-based backup tool) schedules its work that doesn't get enough attention: it depends on WP-Cron, a scheduling system that isn't actually a real cron job. It's a fake one, built entirely out of website traffic.
That single design detail is the difference between "my backup runs on schedule" and "my backup runs whenever someone happens to load a page." For a busy site, the difference is invisible. For a low-traffic blog, a staging site, a seasonal business site, or anything on shared hosting with aggressive resource limits, it's the reason people discover — usually during a disaster, which is the worst possible time — that their "automatic" backup hasn't actually run in weeks.
This article breaks down exactly how WP-Cron works, why it fails in predictable and well-documented ways, what that means specifically for UpdraftPlus users, and how a backup process that never touches WP-Cron at all — because it's triggered externally over SSH — sidesteps the problem entirely.
Quick Answer: Does UpdraftPlus's Backup Schedule Actually Run on Time?
Not always, and the reason isn't a bug in UpdraftPlus — it's the visitor-triggered design of WordPress's built-in scheduler, WP-Cron. WP-Cron only checks for due tasks when a page on your site loads, so a scheduled backup on a low-traffic site can sit "due" for hours or days until a visitor (or a page-cache-bypassing request) happens to trigger it. Add a host that disables WP-Cron, a page-caching layer that serves cached HTML without ever hitting PHP, or a plugin conflict, and the backup can silently stop running altogether — with no error message, because from WordPress's point of view nothing failed; the check for the job simply never ran. UpdraftPlus's own documentation acknowledges this class of problem directly, describing it as a "missed schedule" condition and pointing site owners toward real server cron as the fix. BackupYourSite avoids the entire failure mode by triggering backups over SSH from outside WordPress, so the backup runs on a real, host-level schedule regardless of traffic, caching, or plugin state.
How WP-Cron Actually Works (And Why "Cron" Is a Misleading Name)
Real cron — the Unix scheduling daemon that's run continuously in the background of every Linux server since the 1970s — checks a system clock and fires jobs at exact times, independent of anything else happening on the machine. WP-Cron is not that. It's a WordPress-level simulation of a scheduler, and it works completely differently:
- Every time a page on your WordPress site is requested — a visitor loading a post, a search engine crawler, an API call — WordPress checks a file called
wp-cron.phpto see if any scheduled tasks are "due." - If a task is due, WordPress fires off a separate HTTP request to
wp-cron.phpin the background to actually run it, then continues serving the original page request. - If no page load happens,
wp-cron.phpnever gets checked, and due tasks simply wait.
In other words: WP-Cron has no concept of time passing when nobody is looking. A backup scheduled for 2:00 AM will not run at 2:00 AM. It will run the next time WordPress detects that 2:00 AM has already passed — which could be the moment your first visitor of the day loads the homepage at 9:15 AM, or it could be never, if the site's next request never triggers the check correctly.
Why This Breaks Down Specifically on Shared Hosting
The traffic-triggered design is a reasonable trade-off for a system that has to run on millions of hosting environments with no admin-level access to a real crontab. But it interacts badly with several extremely common shared-hosting conditions:
- Low-traffic and staging sites. A portfolio site, a client staging environment, or a seasonal business site might go hours without a single page view. WP-Cron simply doesn't fire during that window — including overnight, which is exactly when most backup schedules are set.
- Full-page caching. Plugins like WP Super Cache, W3 Total Cache, LiteSpeed Cache, or a host-level cache (common on managed WordPress hosts) serve a static HTML snapshot for most visits, which means the request never reaches PHP at all — and if PHP never runs,
wp-cron.phpnever gets its chance to check for due jobs. DISABLE_WP_CRONset inwp-config.php. Many hosts and security-hardening guides recommend disabling the default WP-Cron behavior in favor of a real server cron job hittingwp-cron.phpon a fixed interval — a legitimate fix, but if that replacement server cron job is itself misconfigured, missing, or later removed during a hosting migration, WP-Cron silently goes dark with no fallback and no warning inside wp-admin.- Shared-CPU throttling and PHP execution limits. Even when
wp-cron.phpdoes fire, it's competing for the same limited CPU/memory allowance and PHPmax_execution_timeas the rest of the site. A backup job — especially the archive-and-upload stage on a site with a large media library or database — can get killed partway through by a resource limit before it finishes, which some hosts report as a normal page timeout rather than a distinct backup error. - Plugin and theme conflicts. Any plugin that hooks into
initor filters cron scheduling can interfere with WP-Cron's job queue. UpdraftPlus's own troubleshooting documentation walks through checking for missingupdraft_backup_databasecron entries and re-saving the backup schedule to force WordPress to re-register the job — an indicator of how often the underlying schedule entry itself can quietly disappear.
None of this is a defect unique to UpdraftPlus. It's true of virtually any plugin-based WordPress tool — backup, security scanning, SEO sitemap regeneration — that relies on WP-Cron for scheduling. UpdraftPlus is simply the most widely installed example, so it's the one most site owners actually encounter this with.
What This Looks Like in Practice for UpdraftPlus Users
UpdraftPlus's own support documentation is candid about the failure class, publishing a dedicated troubleshooting guide for what it calls the "missed schedule" error, plus separate guides for backups that "stop mid-way" and backups that fail to run at all. The consistent theme across all three: the fixes are things a site owner has to notice and manually diagnose — checking wp-config.php for a DISABLE_WP_CRON line, installing a separate plugin (WP Crontrol) just to inspect whether the cron event is even registered, confirming the site gets enough organic traffic to trigger checks, or asking a hosting provider to set up a real server-level cron job as a workaround.
That's a reasonable set of fixes — but notice what they have in common: every one of them requires you to already suspect something is wrong. UpdraftPlus doesn't proactively alert most free-tier users the moment a schedule silently stops firing, because from inside WordPress there often isn't a distinct "cron didn't fire" event to alert on — the job just never entered the queue-check to begin with. The failure mode is invisible by construction, not by oversight.
This is separate from UpdraftPlus's storage architecture, which is genuinely solid — it supports pushing completed backups to a wide range of true offsite destinations (Dropbox, Google Drive, Amazon S3, and its own UpdraftPlus Vault). The storage isn't the weak link. The trigger is: if the backup job never starts because WP-Cron never checked for it, having excellent offsite storage destinations doesn't help, because there's nothing to upload yet.
UpdraftPlus Pricing, for Context
UpdraftPlus is free for core functionality (manual and scheduled backups to one storage destination, restore, and site migration). The paid tier, UpdraftPlus Premium, is licensed per year and scales by number of sites — a Personal license covers 2 sites, running up through Business, Agency, and Enterprise/Gold tiers that cover 10, 35, and unlimited sites respectively, with the top Gold tier adding UpdraftCentral remote management and larger built-in cloud storage. Premium unlocks features like incremental backups, automatic pre-update backups, database encryption, and additional storage destinations — none of which change how the backup is scheduled, since that still runs through the same WP-Cron mechanism on both the free and paid tiers.
How BackupYourSite Avoids WP-Cron Entirely
BackupYourSite's backup process doesn't live inside WordPress at all, which is the core architectural difference from UpdraftPlus and every other plugin-based tool:
- The trigger is external, over SSH — not a WordPress hook. Backups are initiated from outside the site, connecting directly to the server via SSH and running on the host's own real, system-level scheduler. There's no
wp-cron.phpin the chain, so there's nothing for a page-cache layer, a quiet traffic day, or aDISABLE_WP_CRONflag to interrupt. The job starts at the time it's scheduled for, every time, because it's driven by the same kind of dependable system clock that runs the rest of the server — not by whether a visitor happened to load a page. - No PHP execution limits in the critical path. Because the backup isn't running as a WordPress page request, it isn't subject to
max_execution_time, PHP memory limits, or the shared-CPU throttling that can kill an in-plugin backup job partway through on budget hosting plans. - No plugin conflicts to break scheduling. There's no cron hook for another plugin to interfere with, no cron event entry that can silently vanish from the options table, and nothing that needs re-saving after a WordPress core or plugin update resets a setting.
- The backup and the site are decoupled by design, not just by storage destination. Even a perfectly configured UpdraftPlus setup still depends on WordPress being alive and reachable long enough to notice the schedule is due. An SSH-triggered backup doesn't need WordPress to be functioning correctly at all — it can pull files and a database dump directly from the server even if the site itself is throwing errors, which matters most in exactly the scenario a backup exists for: something has already gone wrong with the live site.
This is the same principle discussed in our comparison of why WordPress backup plugins fail structurally — a backup's reliability is set by its trigger and storage location, not by how good the plugin's settings screen looks.
UpdraftPlus vs BackupYourSite: Side-by-Side
| UpdraftPlus | BackupYourSite | |
|---|---|---|
| Backup trigger | WP-Cron (fires on page load / visitor traffic) | External SSH connection on a real server-level schedule |
| Runs if the site has near-zero traffic that day | Not reliably — WP-Cron may never check for the due job | Yes — trigger doesn't depend on visitors at all |
| Affected by full-page caching | Yes — cached pages can bypass PHP and WP-Cron entirely | No — doesn't route through WordPress's request cycle |
| Subject to PHP execution/memory limits | Yes — backup job runs as a PHP process inside WordPress | No — runs outside the WordPress/PHP request lifecycle |
| Needs WordPress to be functioning to back up | Yes — the plugin has to load and execute inside wp-admin/cron | No — pulls files/DB directly over SSH even if WP is erroring |
| Silent-failure risk | Documented "missed schedule" and mid-backup-stop issues in UpdraftPlus's own troubleshooting docs | Failure is a connection/job-log event, not a hidden queue-check miss |
| Storage destinations | Dropbox, Google Drive, Amazon S3, UpdraftPlus Vault, and others | Offsite by design as part of the SSH-based architecture |
| Free tier available | Yes — core scheduled backup, one storage destination | Varies by plan — see current pricing |
| Best fit | Sites with steady daily traffic and standard hosting | Sites where schedule reliability can't depend on visitor patterns — low-traffic sites, staging environments, agencies managing many client sites |
Is This an UpdraftPlus-Specific Problem?
No — and it's worth being precise about that, because the goal here isn't to single out one plugin unfairly. WP-Cron's traffic-triggered design is a WordPress core mechanism, not something UpdraftPlus built. Any WordPress plugin that schedules recurring work — backups, SEO sitemap regeneration, email digests, security scans — inherits the exact same limitation unless it's specifically engineered to route around it (for example, by instructing users to disable native WP-Cron and wire up a real server cron job instead, which UpdraftPlus's documentation does recommend as a fix).
What makes it worth calling out for backups specifically is the stakes: a missed SEO sitemap refresh is a minor inconvenience you'll probably notice within days. A missed backup is invisible until the moment you actually need to restore — at which point discovering the last successful backup is three weeks old, right when your site is down or hacked, is about the worst possible time to learn that the scheduler quietly stopped working.
Frequently Asked Questions
Does UpdraftPlus have a bug that causes backups to fail?
Not a bug in the traditional sense — the behavior comes from WordPress's own WP-Cron scheduling system, which only checks for due tasks when a page on the site is requested. UpdraftPlus's documentation has dedicated troubleshooting guides for "missed schedule" errors and backups that stop mid-way, both of which trace back to this scheduling design rather than a defect in the plugin's backup logic itself.
How do I know if my UpdraftPlus scheduled backups are actually running?
Check UpdraftPlus's own backup history log inside wp-admin for the dates of the last few completed backups and compare them against your configured schedule. If there's a gap longer than your schedule interval, WP-Cron likely isn't firing reliably — common causes include low site traffic, full-page caching, or DISABLE_WP_CRON being set in wp-config.php without a replacement server cron job in place.
Can I fix WP-Cron reliability without switching backup tools?
Partially. Setting up a real server-level cron job to call wp-cron.php on a fixed interval (bypassing the traffic-triggered check) is the standard workaround, and most hosts support it. It fixes the scheduling trigger but doesn't address the other structural issues — PHP execution limits, dependency on WordPress being functional, and exposure to whatever is happening on the same server as the site.
What does "SSH-triggered" backup mean, and why does it avoid WP-Cron?
It means the backup job is started by connecting directly to the server over SSH and running on the server's own operating-system-level schedule — the same kind of real cron that runs other system maintenance tasks — instead of relying on WordPress's page-load-triggered WP-Cron. Because the trigger never passes through WordPress at all, page caching, plugin conflicts, PHP execution limits, and low visitor traffic have no way to interfere with whether the backup starts on time.
Is BackupYourSite a WordPress plugin?
No — that's the core design difference described in this article. The backup process runs externally over SSH rather than as a WordPress plugin, which is what allows it to avoid WP-Cron's traffic-dependent scheduling and PHP's execution limits entirely.
Is UpdraftPlus still a good choice for WordPress backups?
For sites with consistent daily traffic, standard (non-aggressive) caching configuration, and reasonable hosting resources, UpdraftPlus's free and premium tiers work as documented for a large share of installs. The considerations in this article matter most for low-traffic sites, staging environments, and anyone who has already experienced a gap in their backup history without an obvious error message explaining why.
The Bottom Line
WP-Cron was a reasonable engineering compromise for a CMS that has to run on every hosting environment imaginable, with no guarantee of shell access or a real crontab. But "reasonable compromise" and "dependable backup trigger" are different things, and the gap between them is exactly where scheduled backups quietly stop running without anyone noticing. If your site has steady traffic and standard hosting, UpdraftPlus's WP-Cron-based schedule will probably work fine indefinitely. If it doesn't — low-traffic periods, aggressive caching, a hosting migration that dropped a server-cron workaround — the failure will be silent, and you'll only find out at restore time.
An SSH-triggered backup process removes that question entirely by never routing the schedule through WordPress in the first place. The backup runs on the server's real clock, independent of visitors, caching, or plugin state — which is what "automatic" should have meant to begin with.