CDN SLA Credits: What CloudFront, Azure CDN, Cloud CDN, and Spaces Pay When the Edge Fails
September 25, 2026
Your CDN looks like the safest part of the stack. Content is cached at dozens of edge locations, so a failure in one region barely registers. The SLA behind it is where that confidence stops. CloudFront, Azure CDN, Cloud CDN, and DigitalOcean Spaces all commit to between 99.9% and 99.95% monthly uptime and all pay service credits when they miss. They just measure that percentage on four different meters, and the meter decides whether an outage you lived through ever becomes money. A 20-minute edge failure earns you 10% of your Cloud CDN bill, nothing from CloudFront, usually nothing from Azure CDN, and nothing from Spaces. The thresholds, deadlines, and evidence follow, provider by provider.
The four promises, side by side
| Provider | Product | Monthly commitment | How downtime is measured | Credit tiers | Claim deadline |
|---|---|---|---|---|---|
| AWS | CloudFront | 99.9% | Your request error rate, averaged across five-minute periods | 10% / 25% / 100% | End of the second billing cycle after the incident |
| Microsoft | Azure CDN | 99.9% | Your independent probes from 5+ locations | 10% / 25% | 60 days from the incident |
| Cloud CDN | 99.95% | Minutes of lost edge connectivity, in five-minute blocks | 10% / 25% / 50% | 30 days from eligibility | |
| DigitalOcean | Spaces (incl. CDN) | 99.9% | Per-bucket five-minute intervals, clock starts when you report | 10% / 25% / 100% | 30 days from month end, written notice within 24 hours |
CloudFront: your error rate, averaged into oblivion
CloudFront's SLA (last updated May 5, 2022) defines Monthly Uptime Percentage as 100% minus the average of per-period error rates: internal server errors returned by CloudFront divided by requests, per five-minute period. The averaging is brutal for short outages. One fully failed five-minute period in a 30-day month moves the monthly number by 0.0116 percentage points. A 15-minute total failure leaves the month at about 99.965%, above the 99.9% line. You need roughly 43 minutes of total failure in a month to breach CloudFront's SLA, or twice that if only half your requests fail.
The claim is mechanical. Open an AWS Support case with "SLA Credit Request" in the subject, include the dates and times of each period with a non-zero error rate plus request logs that document the errors, and have it received by the end of the second billing cycle after the incident. Credits are 10% of your CloudFront bill below 99.9%, 25% below 99.0%, 100% below 95.0%, with a $1 minimum paid against future CloudFront charges.
One line in the exclusions is worth more than the rest of the document: the commitment does not apply to failures that result from using an origin server other than Amazon S3. Front CloudFront with an EC2 origin and the origin goes down, and the resulting errors are contractually your problem. If you want the SLA to mean anything, the assets belong in S3.
Cloud CDN: 99.95%, counted in minutes
Google's Cloud CDN SLA is the only one above 99.9%, and it is the only one that counts downtime in plain minutes: loss of external connectivity through the external IP addresses of your load balancing forwarding rules, caused by Google's systems, in periods of five consecutive minutes. A month allows about 22 minutes of that before the 99.95% line breaks. A 20-minute edge outage puts you in the 10% credit tier.
Two things about this SLA surprise people. Cloud CDN is not a standalone product; it sits behind an external HTTPS load balancer, and the meter is that load balancer's external connectivity. And downtime means total loss of connectivity. Degraded response times and partial failures are not downtime, no matter how your users felt.
Filing runs on a 30-day window from the moment you become eligible, and Google wants your server logs showing the connectivity loss with dates and times. Credit tiers are 10%, 25%, and 50%, capped at half your monthly Cloud CDN bill and applied within 60 days of the request.
Azure CDN: the SLA only your probes can prove
Azure CDN's SLA is 99.9%, but read the measurement clause and the picture changes. Microsoft will review data from any commercially reasonable independent measurement system you operate: agents in at least five geographically diverse locations, testing at least once per hour, fetching a cacheable object between 50KB and 1MB through your CDN hostname. Your uptime percentage is the share of those tests that delivered the object.
So the meter is yours. No probes, nothing to review. The hourly cadence is coarse: a 20-minute outage usually falls between test rounds and costs you nothing, while a one-hour failure the agents happen to sample shows up as roughly 5 to 10 failed tests in a month of about 3,600, just under 99.9%, for the 10% tier. The 25% tier is reserved for months below 99.5%. Claims go in within 60 days of the incident. Azure Front Door is a different product, 99.99% on five-minute probes; the load balancer guide covers it.
Every CDN SLA here measures the edge on a meter you have to operate or prove: CloudFront wants your request logs, Azure wants your probe data, Google wants your server logs, and DigitalOcean wants written notice within 24 hours. No meter, no evidence, no credit.
Spaces: 99.9%, and the clock starts when you call
DigitalOcean's Spaces SLA (last updated December 2, 2025) covers Spaces and its CDN feature: 99.9% monthly uptime per bucket, measured in five-minute intervals without external accessibility. The credit schedule is 10%, 25%, and 100%, with a $1 minimum and credits expiring 90 days after they are issued.
The mechanics work against you twice. Downtime starts accruing only when you report the outage or acknowledge DigitalOcean's report, so a 60-minute failure you notice 30 minutes in counts as 30 minutes, reads as 99.93%, and earns nothing. And you must notify DigitalOcean in writing within 24 hours of the downtime start, or the credit is forfeited entirely. Data loss is excluded, and the evidence they want is application logs with timestamps and bucket identifiers.
What one hour of edge failure is worth
Assume $1,000 of monthly CDN spend and a 30-day month, then compare a 20-minute blip with a full hour of total edge failure:
| Provider | 20-minute outage | 60-minute outage |
|---|---|---|
| CloudFront | $0 (month stays at 99.95%) | $100 (99.86%, 10% tier) |
| Azure CDN | $0 (hourly probes usually miss it) | $100 if agents caught it, else $0 |
| Cloud CDN | $100 (99.95% breached) | $100 (10% tier) |
| Spaces | $0 (needs ~43 minutes counted from your report) | $100 with written notice inside 24 hours, else $0 |
Three of the four can pay the same $100 for a bad hour, the fourth only when your probes were looking. The real difference sits in short outages and in the paperwork. A 20-minute blip pays only on Google, and only because Cloud CDN's 99.95% line leaves about 22 minutes of slack all month. On Azure and DigitalOcean, the same outage usually ends with an unprovable claim: no meter running, or no notice filed.
File like the meter is watching
The next outage is coming. What separates claims that pay from ones that die in support is preparation done beforehand:
- Run probes from at least five locations at hourly frequency as a minimum, and archive the results. Azure's measurement model is the floor for every provider.
- Keep request logs that cover the window (CloudFront) and server logs that show connectivity loss (Cloud CDN).
- Screenshot the provider's status page incident while it is live, with timestamps.
- For Spaces, report the outage the minute you see it, then file the written notice within 24 hours.
- File inside the deadline: end of second billing cycle for AWS, 60 days for Azure, 30 days from eligibility for Google, 30 days from month end for DigitalOcean.
Do this once per provider and the habit sticks. The credit is usually 10% of the month's CDN bill, real money on heavy traffic, for an hour of work. Tools like uptimeaudit.io exist because nobody remembers these windows three weeks after an incident. The SLA is already paid for; the only variable is whether anyone filed.