Quick verdict: A scheduled UpdraftPlus backup can stop running silently — with no error banner — if wp-cron is disabled, blocked, or interrupted by a plugin conflict. BackupYourSite's SSH-triggered, offsite-verified approach is built to surface exactly that kind of failure instead of hiding it.
UpdraftPlus is the most-installed WordPress backup plugin in the world, and for good reason — it's flexible, it supports a long list of cloud storage destinations, and its free tier covers a lot of ground. But there's a failure mode that doesn't get talked about enough: a scheduled UpdraftPlus backup can stop running silently, weeks before anyone notices, because of a plugin conflict, a broken wp-cron trigger, or a site update — and the dashboard can keep looking "fine" the entire time.
This isn't a knock on UpdraftPlus's engineering. It's a structural risk that comes from any backup tool that runs as a plugin inside the same WordPress installation it's protecting. If the site breaks, the thing responsible for backing up the site can break with it — and because nobody is staring at the backup settings page every day, that break can go unnoticed until the moment you actually need a restore.
This article covers how UpdraftPlus actually works, the specific ways its scheduled backups can silently fail, a practical checklist for verifying your own backups are real, a side-by-side comparison with BackupYourSite's offsite, verification-first approach, and an FAQ section addressing the most common questions site owners ask about backup reliability.
Quick Answer: Can UpdraftPlus Backups Fail Silently?
Yes. UpdraftPlus schedules backups through WordPress's wp-cron system (or, in some setups, a real server cron job calling wp-cron.php). If wp-cron is disabled, blocked by a caching plugin, throttled by low site traffic, or interrupted by a conflicting plugin loading its own JavaScript or cloud-storage libraries on the same admin page, a scheduled backup can simply not run — with no error banner, no site-breaking crash, and nothing forcing you to notice. The backup plugin's settings page can still say "Last backup: [old date]" without ever surfacing that as an alert, because there's no independent system checking on it from outside the WordPress install.
The fix isn't necessarily "install a different plugin." It's adding a verification layer that lives outside the site — one that checks whether a backup actually completed, rather than trusting the same system that failed to also report its own failure.
How UpdraftPlus Works Today
UpdraftPlus operates as a WordPress plugin with a free version and five paid subscription tiers (Personal, Business, Agency, Enterprise, and Gold), priced from roughly $70/year for two sites up to $399/year for unlimited sites with 50GB of UpdraftPlus-hosted storage. Its core mechanism is straightforward and well-established:
- Scheduling runs through WordPress's
wp-cron, letting users choose daily, weekly, monthly, or custom intervals. Paid tiers add "automatic backups before every core or plugin update," which is a genuinely useful safety net — when it fires correctly. - Storage destinations cover a long list of third-party cloud providers: Dropbox, Google Drive, Amazon S3, OneDrive, Microsoft Azure, Google Cloud, Rackspace, MEGA, OpenStack Swift, and generic FTP/SFTP, plus UpdraftPlus's own storage on higher tiers. Paid users can push a backup to more than one destination at once for redundancy.
- Incremental backups (paid tiers) only save what's changed since the last full backup, which cuts down on both backup time and storage use.
- Reporting includes what UpdraftPlus describes as detailed reports showing when a backup ran, what it included, and whether it completed — visible from inside the WordPress admin, and optionally emailed.
On paper, this is a solid feature set. The catch is architectural, not a knock on any individual feature: every part of this system — the scheduler, the backup job itself, and the reporting on whether it worked — runs from inside the same WordPress installation. If something inside that installation misbehaves, the reporting can misbehave right along with the backup job it's supposed to be reporting on.
Why Scheduled Backups Go Silent
Site owners and WordPress support forums have documented several specific, recurring ways a plugin-based scheduled backup can quietly stop functioning:
1. wp-cron Isn't a Real Cron Job
wp-cron doesn't run on a fixed clock in the background. It's triggered by visitor traffic — a page load checks whether a scheduled task is due and fires it if so. A low-traffic site, a site behind aggressive full-page caching, or a site with DISABLE_WP_CRON set (common on managed WordPress hosts that use a real server cron instead) can leave scheduled tasks — including backups — waiting for a trigger that never reliably arrives. If the site's real server cron job calling wp-cron.php is misconfigured, mistyped, or quietly removed during a hosting migration, the same thing happens: the schedule looks "enabled" in the UpdraftPlus settings, but nothing actually fires it.
2. Plugin Conflicts on the Same Admin Page
A newly installed plugin can load its own version of a JavaScript library or its own cloud-storage API on the same admin page UpdraftPlus uses, colliding with UpdraftPlus's own scripts. This can silently prevent a backup from starting, or prevent a completed backup file from actually uploading to its remote destination — while the local WordPress process shows no fatal error.
3. Core, Theme, or Plugin Updates
WordPress core updates, theme updates, and plugin updates change code that a backup process depends on — hooks it relies on, functions it calls, file paths it expects. An update elsewhere in the stack can break a scheduled backup's ability to run to completion, without ever touching the backup plugin's own files.
4. PHP Execution Limits on Larger Sites
Because the backup job runs inside PHP, it inherits PHP's constraints: max_execution_time, memory_limit, and upload_max_filesize. A site with a large media library or a growing database can produce a backup job that gets cut off mid-run on a shared host — resulting in a truncated or corrupted archive that can look complete in the dashboard but fails the moment someone tries to restore from it.
5. Outdated Plugin Version
An outdated UpdraftPlus install is one of the most common causes cited for failed backups — a fix that's easy to apply once you know to look for it, but easy to miss for months on a site nobody is actively watching.
None of these failure points require a crash, an error page, or anything visible to a normal site visitor. That's exactly what makes them dangerous: the failure is invisible until the day a restore is actually needed.
How to Check If Your Backups Are Actually Running
Whether you're on UpdraftPlus, another plugin, or an offsite service, run through this checklist on a recurring basis — monthly at minimum, and immediately after any plugin, theme, or core update:
- Open the backup plugin's history/log, not just the dashboard summary. A green checkmark on the main screen can be stale. Look at the actual timestamp of the most recent completed backup, not the "next scheduled" date.
- Confirm the backup file exists at the remote destination, not just inside the WordPress admin. Log into Dropbox, Google Drive, S3, or wherever it's supposed to land, and verify a file was written with a recent timestamp and a reasonable file size (a near-zero-byte file is a red flag even if it "shows as complete").
- Check email delivery, if the plugin sends completion/failure emails. Confirm the emails are actually arriving (not filtered to spam) and that you're reading them, not just archiving them unread.
- Verify wp-cron is actually firing. A plugin like WP Crontrol, or a quick server-side check with your host, can confirm whether scheduled tasks are running on time or backing up in a queue.
- Run a test restore periodically, ideally to a staging environment. A backup file that exists is not the same as a backup file that restores cleanly — corruption and incomplete archives often only surface at restore time.
- Re-check after every plugin install, theme change, or core update. These are the most common trigger points for a previously-working schedule to quietly break.
- Set a calendar reminder, because none of the above happens automatically unless something outside the WordPress install is forcing the check.
If most of these steps require you to remember to do them manually, that's the actual gap — not a flaw in any one plugin, but the absence of an independent system checking on your behalf.
The BackupYourSite Approach: Verification Instead of Trust
BackupYourSite is built around a different assumption: don't trust a backup because the tool that made it says it succeeded — verify it independently, from outside the system that could fail.
- No WordPress plugin dependency. Backups run over SSH/SFTP at the server level, outside PHP's execution limits and outside the WordPress plugin ecosystem entirely. A conflicting plugin, a broken
wp-cron, or a bad core update has nothing to interfere with, because the backup process isn't running through any of those systems. - Independent verification, not self-reporting. Because the backup process is decoupled from the site's own PHP environment, a failure on the site side doesn't also disable the reporting on that failure — the two are no longer the same point of failure.
- Daily email summaries. Instead of a status buried in an admin dashboard you have to remember to visit, you get a recurring email confirming what happened — turning backup verification from a manual chore into a passive habit.
- Restore logs. A record of what was backed up and when, so a "successful" backup can actually be checked against history rather than taken on faith.
- Fully offsite storage, so the backup isn't exposed to the same server-wide risks — malware, disk failure, hosting account suspension — that could take out the live site.
The goal isn't to claim UpdraftPlus is a bad tool. It's a genuinely capable plugin with a large, well-supported feature set. The goal is closing the specific gap that any in-WordPress backup tool has by definition: when the thing responsible for the backup and the thing responsible for reporting on the backup are the same system, a single failure can take both down at once, silently.
UpdraftPlus vs BackupYourSite: Side-by-Side
| UpdraftPlus | BackupYourSite | |
|---|---|---|
| Runs as | WordPress plugin (PHP, inside the site) | Server-level (SSH/SFTP), outside WordPress |
| Scheduling mechanism | wp-cron (traffic-triggered) or server cron calling wp-cron.php | Independent scheduler, not tied to site traffic |
| Failure visibility | Dashboard status + optional email; can go stale if the site itself is the thing malfunctioning | Daily email summary + restore log, generated independently of the site's own state |
| Exposure to plugin conflicts | Yes — shares the WordPress plugin environment with every other installed plugin | No — no plugin layer to conflict with |
| PHP execution limits | Yes — inherits max_execution_time, memory_limit, etc. | Not applicable — runs outside PHP |
| Storage destinations | Dropbox, Google Drive, S3, OneDrive, Azure, GCS, MEGA, FTP/SFTP, and more | Offsite storage, decoupled from the hosting account |
| Pricing model | Free tier + 5 paid tiers, $70–$399/year | Service-based, verification included |
| Best fit | Site owners comfortable managing and periodically auditing plugin-based backups themselves | Site owners and agencies who want independent verification without manual checking |
Frequently Asked Questions
Does UpdraftPlus send an alert if a scheduled backup fails?
UpdraftPlus offers reporting and, on some configurations, email notifications about backup status. Whether an alert actually reaches you depends on the underlying trigger for the backup (wp-cron) still functioning — if the scheduling mechanism itself is silently broken (due to low traffic, a caching conflict, or a disabled cron), the failure-reporting logic tied to that same mechanism may never run either.
Why would a backup that "completed successfully" fail to restore? A backup job can be cut off mid-run by PHP execution limits on shared hosting, producing a file that looks present and complete in a dashboard but is actually truncated or corrupted. This is why a periodic test restore is more reliable than trusting a completion status alone.
Is a plugin-based backup ever a bad idea? Not necessarily — for a low-traffic personal site with an owner who checks in regularly, a well-maintained plugin like UpdraftPlus, kept updated and paired with manual spot-checks, can work fine. The risk grows with site complexity, traffic volume, the number of other plugins installed, and how infrequently anyone actually looks at the backup settings page.
What's the single most common reason UpdraftPlus backups stop working?
Recurring causes reported by users include an outdated plugin version, a newly installed plugin loading conflicting scripts on the same admin page, and wp-cron not firing reliably due to caching, low traffic, or hosting configuration — each capable of stopping scheduled backups without triggering any visible error.
How is BackupYourSite different from just using a "better" backup plugin? The difference isn't feature count — it's architecture. Any backup tool running as a WordPress plugin shares fate with the site it protects: if the site's plugin environment breaks, the backup and its own status reporting can break together. BackupYourSite runs at the server level, outside the WordPress plugin stack, and layers independent verification (daily email summaries, restore logs) on top, so a failure on the site side isn't also a failure of the system meant to catch it.
How often should I verify my backups are actually running, regardless of which tool I use? At minimum, monthly — and immediately after any core, theme, or plugin update, since those are the most common trigger points for a previously-working backup schedule to quietly stop functioning. Use the checklist above as a starting point.
The Bottom Line
UpdraftPlus is a capable, widely used plugin with a real feature set and a lot of flexibility in where backups get stored. But every plugin-based backup tool shares one structural weakness: when the scheduler, the backup job, and the failure reporting all run inside the same WordPress installation, a single point of failure can quietly take out all three at once — and nothing outside that system is checking on it unless you build that check yourself.
If you're staying with UpdraftPlus, run the verification checklist above on a recurring schedule — don't rely on the dashboard alone. If you'd rather not carry that manual burden, an offsite, verification-first approach like BackupYourSite's is built specifically to close that gap: independent of the site's own PHP environment, with daily summaries and restore logs that confirm a backup happened, rather than asking you to trust that it did.