Force Majeure and the Exclusions That Quietly Sink SLA Claims
September 4, 2026
The outage was real and the claim still died, on a clause nobody read. Every one of the big four's SLAs carries exclusions that strip unavailability out of the uptime calculation, and the exclusion for "factors outside of our reasonable control" is broad enough to swallow more claims than most teams expect. Knowing where the lines sit, and which side of them your evidence lands on, is the difference between a paid claim and a polite rejection.
What the four SLAs actually exclude
The wording differs, the structure repeats: causes beyond the provider's control, your own actions and equipment, and policy violations.
| Provider | Exclusion clause highlights | Where it is written |
|---|---|---|
| AWS | Unavailability caused by factors outside reasonable control including force majeure and internet problems beyond the demarcation point; your actions or inactions; your equipment, software or technology; suspension or termination of your account | Each per-service SLA, Exclusions section |
| Azure | Excluded from Downtime: features in preview, your configuration and software, failures caused by third-party hardware or software, and Scheduled Downtime published at least five days ahead | Consolidated Online Services SLA, General Terms and per-service terms |
| Errors caused by factors outside reasonable control; your software or hardware or third-party software or hardware; abuses violating the Agreement; system or admin console quotas | Each product SLA, SLA Exclusions | |
| DigitalOcean | Scheduled maintenance and customer-initiated downtime; force majeure, third-party outages, customer equipment or network issues; account restrictions or misuse; your application code or configuration errors | Per-product SLA pages, Exclusions |
Read the second line of each row again. The "your equipment, software or technology" family of exclusions is where self-inflicted outages hide: a misconfigured health check that flaps, a DNS record you control that points nowhere, an autoscaling policy that kills instances. When your evidence shows the failure originated on your side, the provider correctly subtracts those minutes from the uptime math. Teams sometimes read this as bad faith; it is not, it is the contract working as written.
The force majeure boundary, in practice
"Outside of our reasonable control" sounds like a get-out-of-jail card, and providers do use it, but it has a defensible boundary. A hurricane knocking out a datacenter's power is the textbook case. An internal DNS automation bug wiping the service's own endpoint records, as happened in the October 19, 2025 us-east-1 DynamoDB event, is not: the failure ran entirely inside the provider's control plane, and AWS published a detailed root cause with a race condition in its own systems as the cause. No reasonable reading of force majeure covers a provider's own automation deleting its own DNS records.
The genuinely contested middle is third-party dependency failure. The SLAs handle this unevenly. DigitalOcean's Droplet exclusion list names "third-party outages" explicitly, so if your Droplet goes dark because an upstream network provider failed, the exclusion applies. Azure's and Google's wording turns on "factors outside of reasonable control", which in past incidents has been argued both ways. AWS's demarcation-point language is the most precise: internet access problems beyond the demarcation point of the service are excluded, so failures inside the provider's network are not.
The exclusions decide what counts as downtime, and the evidence decides which side of the exclusion your incident sits on. Claims are won by placing the failure inside the provider's control plane, with logs that show exactly where the packets stopped.
Building evidence that survives an exclusion review
The claim file should pre-empt the exclusion reading, not discover it in the rejection letter. Four practices do that.
Capture both sides of the failure. Your external probe shows the endpoint dying; your internal logs show your own application healthy until the moment the provider's endpoint stopped answering. The pairing is what proves the failure originated on the provider's side.
Timestamp in UTC, every time. Exclusion reviews check your claimed windows against the provider's own incident record. Clock skew between your servers and the provider's is the cheapest way to lose a valid claim; NTP-sync everything and say so.
Isolate your own changes. If you deployed within hours of the outage, say so proactively and show the deployment window. A reviewer who finds an undisclosed deploy on their own assumes the worst; one who sees it disclosed and bracketed by healthy probe checks moves on.
Quote the SLA back. Name the exclusion you believe does not apply and why, in one sentence. "The failure originated in the provider's DNS management automation per the provider's own post-incident summary, which is within the reasonable control of the provider" is the sentence that survived more than one review.
When the claim is genuinely excluded
Sometimes the exclusion is simply correct, and filing again with the same evidence wastes goodwill. The productive responses: check whether a different service tier carries a different SLA (the exclusion that killed a Droplet claim may not exist on the Spaces claim for the same outage window), and check whether the failure period actually moved the monthly number enough to matter. The covered-outage exclusions piece goes deeper on the exclusion taxonomy, and the appeal path covers the case where you believe the exclusion was applied in error.
UptimeAudit watches the big four's health feeds and matches breaches to the published SLA terms, exclusions included, before drafting the claim. The cheapest exclusion battle is the one you never file.