Which SLA Version Governs Your Claim? The Answer Changes the Credit
September 2, 2026
The SLA that decides your claim is the one in force on the incident date, and it is probably not the one you read when you signed up. Google keeps ten archived versions of its Compute Engine SLA, the oldest from October 2015, with the current one last modified March 4, 2025. Microsoft reissues the consolidated Online Services SLA roughly monthly; the edition dated August 10, 2026 is the one in force as of this month. DigitalOcean split its single SLA into per-product pages, each stamped with its own last-updated date. If you cannot name the version that covered your outage, you cannot file an accurate claim.
How each provider versions its SLA
The four providers treat the document differently, and the differences matter when you are assembling a claim.
| Provider | Document model | Version history | What changed recently |
|---|---|---|---|
| AWS | Per-service SLA pages | Current pages show a Last Updated date; a "Prior Version(s)" page archives older editions | The EKS SLA was updated March 20, 2026, splitting Standard and Provisioned control plane commitments at 99.95% and 99.99% |
| Microsoft Azure | One consolidated SLA for Microsoft Online Services, downloadable as a docx | Reissued roughly monthly; the licensing site keeps an archive | VM credit tiers were restated in the current edition; claims must arrive within 60 days of the incident |
| Google Cloud | Per-service SLA pages | Each page links a dated "Previous versions" section | The Compute Engine SLA was last modified March 4, 2025, with single-instance SLOs and region-specific commitments for Mexico and Stockholm |
| DigitalOcean | Per-product SLA pages under digitalocean.com/sla | The old single SLA URL returns 404; each page shows its own date | The Volumes and DOKS SLAs are stamped June 3, 2025; Regional Load Balancers December 3, 2025 |
Two consequences follow from this churn. First, thresholds you memorized may be stale: Google's GKE SLA was last modified June 29, 2026, moving regional and Autopilot control plane commitments for Mexico and Stockholm down to 99.9%. Second, the claim procedure itself can move, and a claim filed in the wrong format against the wrong edition gets bounced on procedure before anyone looks at your evidence.
Which version governs
The rule is on the incident date, not the filing date. If your outage happened in March and the provider published a new SLA edition in April, the March edition decides your thresholds, your credit schedule, and the claim format. The practical corollary: when an incident happens, capture the SLA page as it stood that day. A screenshot or an archive service snapshot of the SLA URL, saved into the incident folder, ends every later argument about which terms applied.
For Azure the consolidated model makes the capture slightly different: note the edition name and date stamped on the docx, since the document reissues monthly and the archive lives on the licensing site. For DigitalOcean, capture the specific product page for the affected resource, because the Droplet SLA and the Spaces SLA carry different notice rules and different schedules.
The SLA is a living page on all four providers. The edition in force on the incident date governs the claim, and nobody emails you when it changes. Capture it the night it matters.
Where version drift actually costs money
Three recurring drift patterns are worth checking against your own stack.
Commitment changes. AWS's 2022 compute rewrite raised multi-AZ EC2 from 99.95% to 99.99% and added a 99.5% instance-level SLA. A team claiming under the old numbers files against the wrong tier, and the first-tier credit differs by a factor of two: 10% of the affected bill either way, but at a threshold that starts 0.04 points of uptime apart, which is whether your claim exists at all.
Region carve-outs. Google's Mexico and Stockholm regions carry lower multi-zone commitments (99.95%, and 99.9% on GKE) than the rest of the world. If your workload runs there, the breach math differs by region, and claiming the standard tier gets the claim rejected.
Procedure changes. Claim subject lines, required attachments, and submission windows are all in the current edition. AWS's RDS SLA, for example, wants "Amazon RDS SLA Credit Request - Multi-AZ Claim" or "Single-DB Claim" as the exact subject prefix. Older guidance you find in forums may predate the current format.
The version pin, step by step
At incident time, before anything else in the claim process: save a copy of the SLA page for each affected service, note its Last Updated date, and store the URL and capture date in the incident folder. At claim time, cite the edition in the claim text: "under the Amazon S3 Service Level Agreement, last updated November 28, 2023". That one line tells the provider's claim processor you read the right document, which is a small thing that measurably reduces bounce.
The renewal checklist covers how to review SLA versions before you re-sign a contract, and the claim guide keeps the per-provider filing routes current. UptimeAudit tracks the big four's SLA editions against their health feeds, so a breach is matched to the terms actually in force; for a solo operator, a bookmark folder with one dated capture per incident achieves most of the same protection.