UpdraftPlus Backup Failed: When Your Safety Net Has a Hole in It

The false sense of security

UpdraftPlus is the most popular WordPress backup plugin, with over three million active installations. And it deserves that popularity — when it works, it works well. The problem is that "when it works" part. UpdraftPlus depends on server resources, external storage authentication, and WordPress cron — and every one of these can fail without any visible indication on your site.

Your WordPress dashboard does not show a warning banner when the last backup failed. There is no red alert on your admin bar. UpdraftPlus logs the failure in its own settings page, but you have to actively navigate to that page and read the log to know something went wrong. If you set up backups six months ago and have not checked the UpdraftPlus settings page since, you have no idea whether your backups are current.

And that is exactly the problem. Backups are insurance. You do not check them until you need them. And if you discover they have been failing only when you need to restore after a hack, a server crash, or a catastrophic plugin conflict — you have no safety net at the worst possible moment.

Cause 1: Disk space exhaustion from partial backups

This is the most common and the most destructive cause of UpdraftPlus backup failures. When UpdraftPlus creates a backup, it needs to write temporary files to your server's disk. It creates compressed archives of your WordPress files — themes, plugins, uploads, and the database — in the wp-content/updraft/ directory. Once the archives are complete, it uploads them to your remote storage (Google Drive, Dropbox, Amazon S3, etc.) and then deletes the local copies.

Here is what happens when a backup fails midway. UpdraftPlus starts creating the archive, writes 1.2 GB of compressed data to disk, and then the process is killed — by a PHP timeout, a memory limit, or a hosting provider resource limit. The partial archive is left on disk in wp-content/updraft/. It was never uploaded to remote storage. It was never cleaned up.

The next scheduled backup runs. It tries to create new archives, adding another 1.2 GB to the disk. This backup also fails and leaves another partial archive. After a month of daily failed backups, you have 30 partial archives consuming 36 GB of disk space. Your 50 GB hosting plan now has 14 GB free. Your site starts slowing down because the database cannot create temporary tables. PHP cannot write session files. WordPress cannot write to the cache directory.

Eventually, the disk fills completely. WordPress returns a white screen of death or a 500 Internal Server Error. Your site is down — not because of a hack or a server crash, but because your backup plugin filled the disk with failed backups.

How to fix it: Connect to your server via FTP or your hosting file manager. Navigate to wp-content/updraft/. Delete any partial backup files — they are useless for restoration anyway. Check your total disk usage through your hosting control panel. If you are above 80% disk usage, delete old local backups, clear your wp-content/cache/ directory, and remove any other unnecessary files. Then configure UpdraftPlus to retain only 2 to 3 backup copies, not unlimited, to prevent future disk accumulation.

Cause 2: PHP execution timeout

Creating a backup of a WordPress site is a resource-intensive operation. UpdraftPlus needs to scan the entire WordPress directory, compress thousands of files, export the entire database, and upload the resulting archives to remote storage. On a large site — one with thousands of media files, a dozen plugins, and a database with hundreds of thousands of rows — this can take several minutes.

PHP has a max_execution_time setting that limits how long a single PHP process can run. On most shared hosting providers, this is set to 30 to 120 seconds. When the backup process exceeds this limit, PHP kills the process. The backup stops mid-archive, leaving partial files on disk and a failure entry in the UpdraftPlus log.

UpdraftPlus tries to work around this limitation by splitting the backup into smaller chunks. It starts a backup, works for a portion of the allowed time, then schedules a continuation using WordPress cron. The next cron run picks up where the previous one left off. In theory, this allows UpdraftPlus to back up a site of any size regardless of the PHP time limit.

In practice, this chunked approach depends on WordPress cron firing reliably and frequently enough. If cron is unreliable — which it is on low-traffic sites, as we covered in our post about wp-cron not firing — the continuation never runs, and the backup stalls indefinitely.

How to fix it: Check your PHP max_execution_time by creating a file with <?php phpinfo(); ?> and searching for the value. If it is 30 seconds, try increasing it to 300 in your php.ini or .htaccess. If your hosting provider enforces a hard limit, contact them or upgrade your plan. Alternatively, reduce the backup size: exclude large directories like wp-content/cache/, wp-content/updraft/, and any staging site directories. If your media library is very large, consider backing up the uploads directory less frequently (weekly) while backing up the database daily.

Cause 3: Remote storage authentication expired

When you connect UpdraftPlus to Google Drive, Dropbox, or Microsoft OneDrive, the plugin receives an authentication token that allows it to upload files to your account. These tokens have expiration dates. Google Drive tokens typically expire and need refreshing. Dropbox tokens can be revoked if you change your password or if the app is disconnected from your account. OneDrive tokens expire after a set period.

UpdraftPlus stores the authentication token and uses it for every backup. When the token expires, the backup process completes locally — the archives are created successfully on your server — but the upload to remote storage fails. The backup log shows an authentication error. The archives sit on your local disk consuming space. And because the upload failed, there is no off-server backup to restore from.

This is particularly dangerous because you might have months of "successful" backups — but they only exist on the same server as your WordPress site. If the server dies, you lose both your site and your backups. The entire point of remote storage is to have a copy somewhere else. When authentication fails, that safety net disappears.

How to fix it:Go to UpdraftPlus settings and check your remote storage connection. Re-authenticate if the token has expired. For Google Drive, click the "reauthenticate" link and complete the OAuth flow again. For Dropbox, reauthorise the app in your Dropbox account settings. After re-authenticating, run a manual backup and verify it appears in your remote storage account. Set a calendar reminder to check the connection monthly — do not assume it will work forever.

Cause 4: WordPress cron not triggering backups

UpdraftPlus relies on WordPress cron (wp-cron.php) to trigger scheduled backups. WordPress cron is not a real cron system — it only runs when someone visits your site. If your site has low traffic, hours can pass between cron runs. The backup that was scheduled for 3 AM might not actually start until 9 AM when the first visitor arrives.

On some hosting providers, wp-cron.php is disabled entirely for performance reasons. The hosting provider sets up a server-level cron job instead, which calls wp-cron.phpat a fixed interval (usually every 15 minutes). This works well for most WordPress functions, but it can conflict with UpdraftPlus's chunked backup approach. If the server cron and the UpdraftPlus continuation get out of sync, the backup can stall.

How to fix it: Check if wp-cron.php is disabled in your wp-config.php by looking for define('DISABLE_WP_CRON', true);. If it is disabled, make sure your hosting provider has a server-level cron job set up. If they do not, you need to add one yourself through your hosting control panel. Set it to run every 5 minutes: */5 * * * * wget -q -O /dev/null https://yoursite.com/wp-cron.php?doing_wp_cron. The UpdraftPlus plugin page has documentation on cron configuration for different hosting environments.

Why failed backups lead to site outages

Failed backups do not just mean you lack a restore point. They actively cause problems. Partial backup archives accumulate on disk. Log files from repeated failures grow larger. The wp-content/updraft/ directory balloons in size. And the most common downstream consequence is your server running out of disk space.

When a server runs out of disk space, everything breaks at once:

• PHP cannot create temporary files, producing 500 Internal Server Errors
• MySQL cannot create temporary tables, causing database query failures
• WordPress cannot write to its wp-content/cache/ directory
• Your error log grows with each failed request, consuming even more disk space
• Even logging into wp-admin can fail because the session handler cannot write to disk

A disk-full server does not produce a clean error message. It produces intermittent, unpredictable failures. Some pages load. Some return 500. Some load partially. The behaviour changes with every request because it depends on whether PHP happens to find enough temporary space for that specific request.

How Uptrue HTTP monitoring catches disk-full 500 errors

Uptrue's HTTP monitoring checks your site every 60 seconds and verifies the server returns a 200 status code. When your disk fills up and WordPress starts returning 500 errors, Uptrue detects it immediately. You do not discover the problem hours later when a customer emails you about a broken website — you know within a minute.

Step 1: Set up HTTP monitoring on your homepage

1. Sign up at uptrue.io/signup (free plan available)
2. Click Add Monitor from your dashboard
3. Select HTTP/HTTPS as the monitor type
4. Enter your homepage URL
5. Set expected status to 200
6. Set the check interval to 1 minute
7. Configure alerts — Slack, email, or Microsoft Teams

When a disk-full server starts returning 500 errors, Uptrue detects it on the next check. You are alerted within 60 seconds of the first failure.

Step 2: Monitor key inner pages for intermittent failures

Disk-full failures can be intermittent — your homepage might still load from cache while inner pages fail. Set up HTTP monitors on your most important inner pages:

1. Add HTTP monitors for your top 5 pages by traffic
2. Set expected status to 200
3. Set the interval to 5 minutes

Step 3: Add keyword monitoring to catch partial failures

1. Click Add Monitor
2. Select Keyword as the monitor type
3. Enter your homepage URL
4. Set the keyword to a visible heading or your brand name
5. Set check type to "Page must contain"
6. Set the interval to 5 minutes

Keyword monitoring catches cases where the server returns 200 but the page content is incomplete — a partial render caused by a database query failing mid-page because MySQL could not create a temporary table.

Step 4: Monitor your wp-cron endpoint

1. Click Add Monitor
2. Select HTTP/HTTPS
3. Enter https://yoursite.com/wp-cron.php?doing_wp_cron
4. Set expected status to 200
5. Set the interval to 15 minutes

This ensures that WordPress cron is accessible and responding. If your hosting provider blocks access to wp-cron.php or if the file is corrupted, this monitor catches it. A working wp-cron is essential for UpdraftPlus scheduled backups to trigger.

Step 5: Configure alerts for rapid response

• Slack — instant notification when your site returns a 500 error
• Email — documented alert for incident tracking
• Microsoft Teams — visibility for the operations team
• Webhook — trigger automated disk space checks or cleanup scripts

How to make UpdraftPlus backups reliable

Set retention limits

In UpdraftPlus settings, set the number of retained backups to 3 to 5 for both files and database. This prevents old backups from accumulating on your server. Every new backup deletes the oldest one. Without retention limits, backups accumulate indefinitely until your disk fills up.

Exclude unnecessary directories

In UpdraftPlus settings under "Include in files backup," uncheck directories you do not need. Common exclusions: wp-content/cache/ (regenerated by your caching plugin), wp-content/updraft/ (old backups backing up backups), and any staging site directories.

Back up database and files on different schedules

Your database changes frequently — new posts, new orders, new comments. Your files change rarely — only when you update plugins, themes, or upload media. Back up the database daily and files weekly. This reduces the load of each backup job and makes it more likely to complete within your PHP time limit.

Verify remote storage monthly

Log into your Google Drive, Dropbox, or S3 account once a month and verify that recent backup files are actually there. Check the file dates. Download one and try restoring it on a staging server if possible. A backup you cannot restore is not a backup.

Set up a real server cron job

Do not rely on WordPress cron for backups. Set up a server-level cron job through your hosting control panel that calls wp-cron.php every 5 minutes. This ensures the backup triggers on schedule regardless of site traffic.

Your backup is only as good as your last successful run

A backup plugin that ran successfully once, six months ago, is not protecting you. The only backup that matters is the most recent successful one. If that was four months ago because every backup since has been silently failing — from disk space, timeouts, or expired credentials — you are operating without a safety net and you do not know it.

Uptrue cannot monitor your backup plugin directly. But it catches the most destructive downstream consequence of backup failures: your server filling up with partial backup files and your WordPress site going offline with 500 errors. When that alert fires at 3 AM, you know something is wrong with your server before your first morning visitor hits a broken page.

Frequently asked questions