An SLA percentage is not a workload promise
Two documents can print the same availability percentage while covering different services, scopes, and failure events. One may measure a region with instances spread across zones, another a single instance, and a third only the control plane. Credits can depend on a monthly formula and a claim procedure. Engineering review should therefore normalize definitions before comparing numbers.
Keep contractual interpretation with procurement and counsel. The engineering task is narrower: identify what component is covered, how downtime is observed, which topology qualifies, what evidence must be retained, and how operations recover when the workload is unavailable. A credit does not restart training, restore a checkpoint, replace a failed node, or drain an inference queue.
Build a boundary matrix before scoring
Create one row per promised service, not one row per provider. Record covered compute resource, geographic boundary, required deployment topology, measurement period, downtime start and stop definition, excluded events, credit schedule, claim window, and maximum remedy stated in the document. Link each cell to the exact provider text and record the review date because terms can change.
AWS's compute SLA, last updated May 25, 2022, distinguishes a region-level commitment for qualifying deployment across two or more Availability Zones in one region, or at least two regions when a region has only one Availability Zone, from an instance-level commitment for a single instance. The Google Compute Engine SLA version last modified March 4, 2025 defines single instances, instances in multiple zones, downtime periods, monthly uptime percentage, and financial credit. These versions predate this article's assigned publication date and illustrate distinct boundaries, not findings about a particular GPU offer.
| Normalization field | Question for engineering | Evidence to retain |
|---|---|---|
| Covered service | Which resource actually failed? | Resource IDs and service name |
| Topology | What placement qualifies? | Zone and region inventory |
| Measurement | Who starts and stops downtime? | Health and provider event timestamps |
| Exclusions | Which events leave the calculation? | Change and incident records |
| Recovery | How does useful work resume? | Runbook and recovery test |
Recalculate the provider formula separately
Implement each published formula as written in a worksheet or test script. Do not translate every promise into 525,600 annual minutes unless the agreement actually measures annually. A monthly uptime calculation may have thresholds, qualifying downtime periods, topology conditions, and excluded minutes. Preserve raw timestamps so the provider calculation and the internal service objective can be reconstructed independently.
For an illustrative arithmetic check, suppose a definition counts 50 minutes of qualifying downtime in a 30-day month containing 43,200 minutes. Monthly uptime is (43,200 minus 50) divided by 43,200 multiplied by 100, or approximately 99.8843 percent. This is not a claim under any named provider SLA. The document's definitions determine whether those 50 minutes qualify at all.
Separate contractual coverage from operational recovery
Add an engineering recovery column beside every SLA row. Capture failure detection source, escalation route, replacement-capacity method, checkpoint age, data durability dependency, estimated queue impact, and the test that proves service restoration. If the promise covers a VM but the workload needs eight tightly connected GPUs, the recovery unit may be the whole allocation rather than the failed instance.
A useful internal target might be: detect loss within five minutes, make a replacement decision within ten minutes, and resume from a validated checkpoint within sixty minutes. Those figures are illustrative and should come from workload objectives, not from provider language. Measure both provider-defined downtime and time until useful work resumes. The difference exposes operational work that a headline percentage omits.
Test exclusions against real incident categories
Read exclusions with an incident taxonomy beside you. Map facility or provider fault, internet path failure, customer configuration, scheduled maintenance, unsupported software, quota exhaustion, capacity unavailability, security suspension, and force majeure only where the document addresses them. Mark unclear cells for commercial review rather than guessing. Do not compress several clauses into a casual label such as standard exclusions.
AWS explicitly lists categories of exclusions including factors outside its reasonable control, internet problems beyond its demarcation point, customer actions or inactions, customer equipment or software, and suspension or termination under the agreement. That language shows why telemetry and change records matter, but this article does not determine whether any specific outage is excluded. Preserve evidence and use the provider's normal claim and dispute process.
Run a diagnostic sequence on each offer
First, identify the exact service and SKU named in the offer. Second, verify the qualifying topology against the proposed architecture. Third, reconstruct the measurement formula from the primary document. Fourth, enumerate exclusions and customer duties without interpreting their legal effect. Fifth, map alerts and logs to the required evidence. Sixth, test the operational recovery path. Finally, identify gaps that need written provider clarification.
Use a pass rule tied to the workload: an offer advances only if every critical dependency has a named coverage status, every recovery objective has a tested or scheduled control, and the team can collect the timestamps and identifiers needed for its own incident review. A higher percentage does not override a failed recovery test. ClusterBid can help compare capacity once the engineering boundary and recovery requirements are normalized.
Work a hypothetical provider comparison
Consider two illustrative offers, not real provider terms. Offer A promises a monthly regional measure only when instances span two zones. Offer B promises a monthly single-host measure but excludes planned maintenance and provides no replacement-capacity objective. The workload is an eight-GPU training job that currently runs in one zone and can restart from a checkpoint within 45 minutes when equivalent capacity exists.
Offer A is not automatically applicable because the proposed single-zone design may fail its topology condition. Offer B may cover the host event, yet still leave an unknown wait for eight replacement GPUs. Engineering should request a topology-qualified design and a documented capacity-recovery path from each bidder. Score the clarified offers on covered boundary, evidence, and recovery, not on the two percentages alone.
Keep the review dated and explicit about limits
Archive the source documents or stable links, revision dates, worksheet, questions, provider answers, architecture diagram, and recovery-test receipt. Re-run normalization when the architecture, service tier, region, or terms change. The public SLA may not be the complete set of terms for a negotiated service, so ensure the review uses the documents that actually apply to the proposed purchase.
This method cannot predict outage frequency or guarantee that a claim will be accepted. It also does not value legal rights or financial remedies. Its value is making unlike promises legible to engineers and exposing whether a team can restore useful GPU work. Commercial and legal specialists should assess contractual effect; operators should own detection, evidence collection, escalation, and recovery testing.