DNS Has the Only 100 Percent Uptime SLAs. Almost Nobody Files the Claims.
September 9, 2026
Every other cloud SLA pays you a consolation percentage. DNS pays you the whole bill. Amazon Route 53, Google Cloud DNS, and Azure DNS are the only services among the big four that commit to 100 percent uptime, and their credit schedules are built differently: miss the mark by a single minute and the payout jumps to 25 percent of the month's DNS bill at AWS, or 100 percent at Azure. A promise of 100 percent anything sounds like marketing, but here it is a contract, with a claim window attached, and almost nobody files.
Why 100 percent is realistic for DNS and nothing else
A DNS answer is a tiny static record served from a global anycast fleet. There is no state to corrupt, no write path to stall, and no region for your zone to be unavailable "in". AWS runs every public hosted zone on four separate name server sets across different top-level domains, precisely so that one catastrophic failure cannot take all four down at once. That is why AWS can put its name on a 100 percent commitment for Route 53 while EC2 tops out at 99.99 percent for multi-AZ deployments.
The flip side is a bar you can actually trip over. A single minute of total failure in a 30-day month is 99.9977 percent. Under a 99.99 percent commitment that minute is absorbed and pays nothing. Under a 100 percent commitment it is a breach, and at AWS it clears the top credit tier on its own.
The definitions differ in ways that decide whether you have a claim at all:
| Provider | "Down" means | Measured on | Credit tiers |
|---|---|---|---|
| AWS Route 53 | All four assigned name servers fail all queries for the whole minute | each hosted zone | 100% below 99.95%, 25% below 99.99%, 10% below 100% |
| Azure DNS | A valid query gets no answer within 2 seconds across all name servers | each DNS zone | 100% below 99.5%, 25% below 99.99%, 10% below 100% |
| Google Cloud DNS | No authoritative name server answers queries for the zone | the zone, in 60-second periods | 50% below 95%, 25% below 99.5%, 10% below 99.5% |
| AWS EC2, for comparison | All instances across AZs have no external connectivity | the region or instance | 100% below 95%, 30% below 99%, 10% below 99.99% |
Read that second column again. Route 53 owes you nothing if three of your four name servers die and the fourth keeps answering. Google's clock only starts after 60 consecutive seconds of total silence. Azure is the odd one out: any valid query that waits more than two seconds counts the minute as unavailable, which makes it both the easiest SLA to breach and the only one where "slow" counts as down. These definitions are why a bad day for DNS is usually not a claim, and why the rare total failure is worth real money.
The whole point of a 100 percent DNS SLA is the top tier. One bad minute is enough to clear it at AWS and Azure, but only if you noticed the minute and file inside the window.
What the credit actually pays
Credits are a percentage of the DNS line on your bill, and DNS bills are small, which is exactly why these claims get ignored. The numbers still favor DNS over almost anything else you run.
Say your public zone costs $0.50 a month and answered 100 million standard queries. At Route 53's $0.40 per million, that zone bills $40.50, and a full failure of one minute puts the zone below 99.95 percent, which pays 100 percent of that: $40.50.
| Monthly spend on the zone | Route 53 credit after a 100% breach | Cloud DNS credit after the same outage |
|---|---|---|
| $4.50 (10M queries) | $4.50 | $0.45 |
| $40.50 (100M queries) | $40.50 | $10.13 |
| $400.50 (1B queries) | $400.50 | $100.13 |
Google pays 10 percent on the first breach band, 25 percent below 99.5 percent, 50 percent below 95 percent. Azure's ladder is the steepest: 25 percent of the bill the moment the zone slips below 99.99 percent, 100 percent below 99.5 percent. One sustained Azure DNS failure can be the single largest credit on an account that month, from a service whose entire bill is often less than a coffee.
The windows, and the one rule that kills Google claims
Every provider makes you ask, and each window works differently:
| Provider | Claim window | Where it counts from | Filing route |
|---|---|---|---|
| AWS Route 53 | end of the second billing cycle | after the incident's cycle closes | AWS Support Center case, "SLA Credit Request" in the subject |
| Azure DNS | 60 days | from the incident itself | Azure portal, Help + support, Billing, Refund Request |
| Google Cloud DNS | 30 days | from when you become eligible | SLA contact form, must come from a Google account |
| DigitalOcean | no DNS product in the SLA list | n/a | n/a |
DigitalOcean deserves its own line: its SLA index covers 14 products, from CPU Droplets to Spaces, and DNS is not one of them. The domain names tool many small accounts rely on carries no published uptime commitment at all.
Google's rule is the one that empties wallets. The 30-day clock starts when you become eligible, not at the end of the month, and eligibility attaches the moment you could have known about the failure. A DNS outage on the 3rd of the month starts a clock that expires early the following month, while your AWS claim for the same incident is still comfortably open. Teams that batch their claims monthly, the sane habit everywhere else, blow straight through it.
How to actually file one
- Capture the failure while it is live: dig queries against all four assigned name servers, with timestamps and output, from outside your network. Do this during the incident, not after.
- Check the definitions before you count minutes. Partial failures, single name server loss, or sub-second latency at AWS and Google do not count. Azure counts anything over two seconds.
- Compute the monthly number yourself: 100 minus the unavailable minutes, divided by the minutes in the month.
- File with the zone identifier, the date and times in UTC, and query logs. Route 53 asks for "request logs that document the errors" with anything sensitive redacted; Google wants logs showing loss of response to name server queries.
Nothing here is hard. The hard part is knowing that a DNS failure was a claimable event while the window is still open, which is the same tracking problem every other SLA credit dies of.
One thing to do today
If your domains sit on Route 53, Azure DNS, or Cloud DNS, find the last incident where resolution actually failed, however briefly, and check it against the tiers above. If any zone dipped below its bar inside the current window, file the claim this week: the money is small, the filing is fifteen minutes, and the habit of checking is what pays out the day a bigger one lands.