# Understanding Cloud Sync Failure Alerts

> SiteVault Pro sends an admin notice and email when cloud sync fails 3 times in a row. What triggers it, how to dismiss it, and how to fix broken credentials.

- Canonical: <https://royalplugins.com/support/sitevault/cloud-sync-failure-alerts/>
- Last updated: 2026-10-09
- HTML version: <https://royalplugins.com/support/sitevault/cloud-sync-failure-alerts/>

---

This page teaches you how to interpret and respond to SiteVault Pro’s cloud sync failure alerts. SiteVault Pro warns you in the WordPress admin and by email when a cloud storage provider fails to accept your backups 3 times in a row. Below you’ll learn what the notice means, when the alert escalates, how to dismiss it, and what to check when a sync starts failing.

Available in SiteVault Pro 1.7.46 and later

The cloud sync failure alert framework ships in all SiteVault Pro tiers (Pro, Business, and Agency). Update to **1.7.46** or later to see the notices and receive the email alerts. Older versions still create backups, but do not warn you when off-site sync stops working.

## What the alert means

SiteVault Pro tracks each cloud storage provider's sync outcomes independently. When a provider fails to accept an uploaded backup 3 times in a row, an admin notice appears at the top of your WordPress admin and an email is sent to the address configured in **SiteVault > Settings** (Email Notifications section). The notice looks like this:

SiteVault:

cloud sync to **DigitalOcean Spaces** has failed 3 times in a row. Last error: The specified bucket does not exist. [Test the connection in Settings.](#)   [Dismiss](#)

Your local backups are still being created on the site. Only off-site sync to that cloud provider is affected. That means data is not lost, but if a disaster took your site down before you fixed the underlying cause, you would only have the local copies to restore from.

## When the alert escalates

SiteVault fires an email at three failure counts. The admin notice re-renders whenever the count grows past your dismissed value (see [Managing dismissal](#dismiss) below).

| Failures in a row | What happens | Email subject |
| --- | --- | --- |
| **1–2** | Silent. Failures are logged internally, no notice or email yet. | None |
| **3** | Admin notice appears. First email fires. | [Your Site] Provider cloud sync failing (3 attempts) |
| **4–9** | Notice re-renders each time the count grows past your dismissed value. | None |
| **10** | Second email fires. Notice keeps re-rendering as count grows. | [Your Site] Provider cloud sync failing (10 attempts) |
| **25** | Third email fires. This is the “something is seriously wrong” threshold. | [Your Site] Provider cloud sync failing (25 attempts) |

The moment a single sync succeeds, either a real backup upload or the twice-daily connectivity probe (see below), the counter drops back to **0** and all three email thresholds re-arm. This is intentional: a provider that stops failing shouldn't have its future problems ignored.

## What usually causes a sync failure

The last error message in the notice and email tells you what the cloud provider returned. Most sync failures fall into one of these categories:

#### Expired or revoked credentials

Access keys, service account tokens, or OAuth refresh tokens can expire or be rotated. Common error: `Access Denied`, `InvalidAccessKeyId`, or `401 Unauthorized`.

#### Bucket deleted or renamed

Someone (or an infrastructure change) removed the destination bucket. Common error: `NoSuchBucket` or `The specified bucket does not exist`.

#### Bucket full or over quota

The destination bucket has hit its storage quota. Common error: `QuotaExceeded`, `storage_quota_reached`, or a 507 Insufficient Storage response.

#### Permission scope reduced

The API key or service account still exists, but its write permission was removed. Common error: `Access Denied` paired with an otherwise valid credential.

#### Provider outage

The cloud provider itself is having an incident. Common errors: `503 Service Unavailable`, `InternalError`, gateway timeouts. Check the provider's status page.

#### DNS or endpoint change

The provider changed its endpoint URL (or a custom domain lapsed). Common errors: `Could not resolve host`, `SSL certificate problem`, or connection timeouts.

## How to fix a failing provider

When you receive the notice or email, work through these steps in order. The steps are the same regardless of which cloud provider is failing.

#### Read the last error message

The notice and email include the exact error string the provider returned on the last attempt. Match it against the categories in the [Common causes](#common-causes) table above. Often the error alone tells you the answer (for example, `NoSuchBucket` means someone deleted the bucket).

#### Test the connection from Cloud Storage

Go to **SiteVault > Cloud Storage**, find the failing provider in the connected providers table, and click **Test**. This runs the same probe the twice-daily reconciler uses. A pass means the credentials work now. The failing backups may have been transient. A fail confirms the credentials or destination are broken.

#### Verify credentials in the provider's console

Log into the cloud provider (AWS, DigitalOcean, Backblaze, etc.) and confirm the access key or service account still exists, is enabled, and has write permission to the destination bucket. If credentials were rotated, generate new ones and update them in SiteVault.

#### Verify the destination bucket

Confirm the bucket still exists, is in the region you configured, and has enough free space. If the bucket was deleted or moved, either recreate it at the original name or reconfigure the SiteVault provider with the new bucket name. The [S3 setup guide](https://royalplugins.com/support/sitevault/setting-up-s3-compatible-providers/) covers bucket, key, and region settings for each S3 provider.

#### Save the provider, then click Sync Now

After fixing the underlying cause, save the provider settings so any updated credentials take effect. Then click **Sync Now** on the provider row in **SiteVault > Cloud Storage** to retry the stalled backups. On success, the failure counter resets to 0, the notice disappears from every user's admin, and the email thresholds re-arm.

Not sure which cloud provider failed?

The notice always names the provider. To see every provider’s state on one page, open **SiteVault > Site Health**. While any provider has failed 3 or more times in a row, the **Cloud Provider Sync** section lists each one with its failures in a row, last error, and last failure time. To check a provider directly, open **SiteVault > Cloud Storage** and click **Test** on its row.

## How the twice-daily reconciler works

SiteVault runs an automatic reconciler every 12 hours as part of the standard health-check cron. The reconciler does two things:

1. **Probes every active cloud provider** with a lightweight connection test. Provider passes → failure counter drops to 0 and the notice/email thresholds re-arm. Provider fails → counter increments by 1 (and may trip the next alert threshold).
2. **Automatically retries stalled backups.** After each successful probe, the reconciler tries to sync the oldest completed backups that haven’t made it to cloud storage yet (default: 5 backups per run, oldest first). This catches up on backlog without requiring a manual click.

The practical effect: if you rotate credentials without updating SiteVault, the reconciler catches it within 12 hours and you get the alert, instead of waiting until the next scheduled backup runs and discovering the problem days later.

Filters for advanced configurations

Two WordPress filters let you tune the reconciler for high-volume sites: `rb_reconciler_batch_size` (default 5, max backups per run) and `rb_reconciler_min_age_minutes` (default 60, minimum backup age before retry). Most sites do not need to change these. See the [SiteVault developer notes](https://royalplugins.com/support/sitevault/) if you need to.

## Managing dismissal

Dismissing the notice is per-user and per-provider. Each user account on your site has its own dismissal state, and each cloud provider is tracked independently.

When you click **Dismiss**, SiteVault records the current failure count as your dismissed value. The notice will re-appear for you only if the failure count grows past that value. Concrete examples:

- You dismiss at **3 failures**. The count grows to **4** at the next attempt. The notice re-appears.
- You dismiss at **10 failures**. The count stays at **10** for a day (no new sync attempts). The notice stays hidden.
- You dismiss at **10 failures**, a sync succeeds, the count resets to **0**, then failures start again. The counter re-crosses 3, 10, 25, every threshold re-fires an email, and the notice re-appears for every user (dismissals reset alongside the counter).

This behavior is intentional. Once you have acknowledged a specific level of failure, SiteVault does not nag you at that level again, but it will always alert you when the problem gets worse.

## Where to configure the notification email

Cloud sync failure emails use the same settings as SiteVault’s other failure notifications:

#### Go to SiteVault > Settings

Scroll to the **Email Notifications** section on the Settings page. This is where you toggle email delivery on or off and set the destination address.

#### Confirm “Enable Notifications” is checked

If this master toggle is off, no sync failure emails are sent regardless of threshold. Backup failure emails and staging notifications are also gated by the same toggle.

#### Set the notification email address

Defaults to the site’s admin email address. Change it if you want alerts to go to a shared inbox or an on-call rotation address.

#### Confirm “Backup or cloud sync failed” is checked

This checkbox, in the **Notify On** list, controls both backup failure emails and cloud sync failure emails. Turn it off only if you monitor failures through a different channel and don’t want any failure emails from SiteVault.

## FAQ

### Do backup files get lost when sync fails?

No. Local backups are created and stored on your WordPress site regardless of cloud sync outcome. Only the off-site copy is missing. Once you fix the underlying cause and click **Sync Now** on the provider row, the stalled backups upload normally, the local copies are the source.

### Does the alert affect my scheduled backups?

No. Scheduled backups continue to create local backup files on the normal schedule. Only the cloud upload step is affected. The scheduled backup itself is marked completed as soon as the local file is written, so cloud sync failures do not show up as failed backups in your Backups list.

### How do I turn off the alert without turning off cloud sync?

You can turn off all failure emails in **SiteVault > Settings** by unchecking the “Backup or cloud sync failed” box in the Email Notifications section. Cloud sync will continue to work, and the admin notice will still appear at 3 consecutive failures, but no email is sent. There is no per-provider mute for the notice itself, since the whole point of the notice is to surface which provider is failing.

### Why do I see the notice on every admin page?

The notice registers on WordPress’s standard `admin_notices` hook, which fires on every admin page in your WordPress dashboard. Dismissing it hides it site-wide for your user until the failure count grows.

### Can other users on the site dismiss the notice for me?

No. Dismissals are per-user. Each administrator sees the notice independently and dismisses it independently. If you have a shared account across a team, everyone using that account shares the same dismissal state.

### The notice shows a failure count of 10 but I only saw one alert email, is that a bug?

No, that is the expected behavior. Emails fire only when the counter *crosses* a threshold (3, 10, 25). Between thresholds, the counter increments silently while the notice keeps re-rendering in the admin. The email pattern is designed to avoid inbox spam while making sure you don’t miss the initial failure or an escalating problem.

### My Site Health score went down, is this related?

Possibly. The **Cloud Provider Sync** check runs alongside the SSL, disk, database, and PHP checks. Its own score drops 30 points for each provider that has failed 3 or more times in a row, which lowers the overall score, the average of all checks (see [Site Health Monitor](https://royalplugins.com/support/sitevault/site-health/#provider-sync)). From SiteVault Pro 1.7.48, the Site Health page names each failing provider in that section, along with its last error, so you can see which one caused the drop. Fix the failing provider and the score returns to normal within 12 hours, when the next twice-daily reconciler run confirms the fix.

[Diagnosing Stuck or Stalled Backups](https://royalplugins.com/support/sitevault/diagnosing-stuck-or-stalled-backups/)
[Back to SiteVault Docs](https://royalplugins.com/support/sitevault/)