Backup SLA Credits: What AWS Backup, Azure Backup and Google Backup and DR Pay When the Vault Fails
October 9, 2026
Your backup service has a service level agreement, and when it fails to back up or restore, you can claim money back. But the backup SLA is the strangest one in the cloud: it does not promise your data is safe, it promises the backup and restore operations work, and it only counts a failure if you keep retrying every thirty minutes. A single missed backup almost never pays. This post lays out the exact commitments, the credit tiers, the retry rules and the deadlines for AWS Backup, Azure Backup and Google Cloud Backup and DR, with the money math that shows what a claim is actually worth.
The commitments, and what they actually cover
All three providers promise around 99.5% to 99.9%, but they measure completely different things. AWS Backup and Azure Backup grade the availability of the backup and restore operations. Google Backup and DR splits the promise into three separate operations, each with its own 99.5% commitment.
| Service | What is measured | Monthly uptime commitment |
|---|---|---|
| AWS Backup | Backup API availability, per 5-minute interval | 99.9% |
| Azure Backup | Backup and restore functionality, per protected item | 99.9% |
| Google Backup and DR, Trigger Backup | Backup trigger requests | 99.5% |
| Google Backup and DR, Delete Backup | Backup deletion requests | 99.5% |
| Google Backup and DR, Restore Backup | Restore requests, Compute and Disk only | 99.5% |
The gap between 99.9% and 99.5% is not small. In a 30 day month, 99.9% allows 43.2 minutes of downtime, while 99.5% allows 216 minutes, three and a half hours. Google's backup service is allowed to be down for over three hours a month before it owes you anything, and that is the most generous promise of the three.
The retry rule that decides most claims
Here is the detail that kills more backup claims than any other. Every provider defines downtime around your own retries, and if you stop retrying, the clock stops.
- AWS Backup counts an interval as failed only when your API actions return an internal server error or a service unavailable error. If you made no requests in a 5 minute interval, that interval is assumed to have a 0% error rate, meaning it counts as fully available.
- Azure Backup considers the service unavailable for a protected item from the first failed backup or restore until a successful one, but only if you keep retrying at least once every thirty minutes. Stop retrying and the downtime stops accumulating.
- Google Backup and DR counts a minute as downtime only when more than 5% of your valid requests fail, and only in blocks of 5 or more consecutive minutes. A single failed restore that you do not retry never becomes a downtime period.
The rule that decides most backup claims: downtime only counts while you keep retrying. A missed backup you do not retry is not an outage, it is a gap in your own process. Set your retry loop to run at least every thirty minutes, or the provider's clock stops before yours does.
The credit ladders
When a breach is real, the payout is a percentage of what you paid for the backup service in the affected month, not of your whole cloud bill. The ladders differ sharply between providers.
| Service | Commitment | Credit tiers |
|---|---|---|
| AWS Backup | 99.9% | 10% below 99.9% · 25% below 99.0% · 100% below 95.0% |
| Azure Backup | 99.9% | 10% below 99.9% · 25% below 99.0% |
| Google Backup and DR | 99.5% | 10% below 99.5% · 25% below 95.0% · 50% below 90.0% |
The asymmetry is worth staring at. AWS will pay 100% of your backup bill if the month drops below 95% uptime. Azure never pays more than 25% for a backup failure, even for a month-long outage. Google tops out at 50%, and its 99.5% bar means a three hour outage in a month does not breach it at all.
What an outage actually pays: two worked examples
The credit basis is the backup service bill, not the data you protected. AWS Backup storage runs about $0.05 per GB-month for warm storage, so a 1 TB estate is roughly a $50 a month backup bill before restores and API charges. Azure bills per protected instance plus storage, and Google Backup and DR bills per GB of protected data. Here is what a one hour and an eight hour outage pay on a $500 a month backup bill, assuming the downtime actually counts.
| Outage length | AWS Backup ($500/mo) | Azure Backup ($500/mo) | Google Backup and DR ($500/mo) |
|---|---|---|---|
| 1 hour | 10% = $50 | 10% = $50 | 0% (under 3.6h allowance) |
| 8 hours | 25% = $125 | 25% = $125 | 10% = $50 |
| 3 days | 25% = $125 | 25% = $125 | 25% = $125 |
| 5 days | 100% = $500 | 25% = $125 | 50% = $250 |
Run the numbers for your own estate and the picture gets uncomfortable. A backup service that fails for a day earns you $50 on a $500 a month bill, while the business cost of losing a day of data is usually orders of magnitude larger. The credits are real, but they are compensation for the backup service being down, not for what the downtime did to you.
What the SLA does not cover
The most important sentence in each of these documents is the one that says what is not promised. None of the three providers guarantees restore speed, restore success for every workload, or the integrity of the data you get back.
- AWS Backup measures API error rates only. A backup job that fails because your agent, your network or your configuration broke does not count, and a restore that returns corrupted data is not an SLA event at all.
- Azure Backup excludes failures caused by your hardware, software or network, and failures from using the service inconsistently with the documentation. The 99.9% promise covers the service being unavailable, not your backup completing.
- Google Backup and DR covers Restore Backup for Compute and Disk only. Restores of databases, file shares and other workloads are outside the SLA entirely, and pre-GA features and quota errors are excluded.
The durability of the backup data itself lives in a different document: the storage SLA of the underlying service. AWS Backup stores recovery points in S3, Azure Backup stores them in Azure Storage, and Google Backup and DR stores them in Cloud Storage. If a recovery point is lost, the claim route is the storage SLA, not the backup SLA, and storage SLAs measure request failures, not data loss. We covered that gap in detail in Data Loss Is Not an SLA Breach.
DigitalOcean: no backup SLA at all
DigitalOcean sells Droplet Backups and Snapshots, but its SLA index covers fourteen products and backups are not one of them. There is no credit schedule, no claim window and no service commitment for backup or snapshot functionality. If a Droplet backup fails or a snapshot cannot be restored, the only recourse is a support ticket and goodwill. For a platform that markets backups as a feature, that is a real gap to price into your own DR plan.
What to save, and where to file
The claim windows match the general rules for each provider, and the evidence list is short if you keep backup job logs.
| Provider | Deadline | What to send | Channel |
|---|---|---|---|
| AWS | By end of the second billing cycle after the incident | Subject line "SLA Credit Request", billing cycle, region, dates and times in UTC, request logs showing the error responses | AWS Support Center case |
| Azure | Within 60 days of the incident | Incident description, time and duration, affected resources, what you tried, Service Health incident ID | Portal: Help + support, Billing, Refund Request |
| Google Cloud | Within 30 days of eligibility | Log files showing the downtime periods with timestamps | Cloud SLA contact form |
The evidence that makes these stick is the retry log. AWS wants request logs that document the claimed incidents, Google explicitly requires log files showing the downtime periods, and Azure wants a description of what you tried. A screenshot of a failed backup job with UTC timestamps beats a status page link every time. Google in particular will not consider a claim without the log files, and its credit, if approved, is applied within 60 days of the request.
One thing to do now
Check your retry configuration before the next incident, not after. For each backup and restore path, ask whether your tooling retries at least once every thirty minutes for the full duration of a failure. If the answer is no, the provider's downtime clock stops while your data is still unprotected, and no claim will ever be valid. Fix the retry loop first, then set a calendar reminder for the claim windows: end of the second billing cycle for AWS, 60 days for Azure, 30 days for Google. The credits are small relative to the cost of losing data, but they are the only compensation the contract gives you, and they do not file themselves.