Understanding Cloud Sync Failure AlertsPRO
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. This guide explains what the notice means, when the alert escalates, how to dismiss it, and what to check when a sync starts failing.
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:
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 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 table above. Often the error alone tells you the answer (for example, NoSuchBucket means someone deleted the bucket).
Test the connection from Settings
Go to SiteVault > Cloud Storage, find the failing provider in the connected providers table, and click Test Connection. 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.
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.
The notice always names the provider. If you have several cloud providers configured and want to check each one directly, open SiteVault > Cloud Storage and click Test Connection on each provider row. A failing provider will surface its most recent error there.
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:
- 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).
- 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.
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 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 failed” is checked
This checkbox (in the Notification Events list) gates 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 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 Health page score went down after 1.7.46, is this related?
Possibly. A new cloud-provider sync check runs alongside the existing SSL, disk, database, and PHP checks starting in 1.7.46 and deducts 30 points per failing provider from the overall health score. The score drops the first time the check runs against a provider that’s currently failing. Fix the failing provider and the score returns to normal within 12 hours (when the next twice-daily reconciler run confirms the fix).