Cloud SLAs: recompute uptime and eligible service credits
A customer’s application outage and a cloud contract’s eligible unavailability can cover different resources and minutes. Even when a service-credit condition is met, the credit usually has a defined billing base and claim process. Research should reconstruct those objects before treating a headline outage as a percentage refund on all cloud spending.
The deliverable is an incident-to-SLA ledger with a separate conditional credit calculation. The example is fictional and does not decide a claim. It uses the publicly available AWS Compute SLA read on October 25, 2026, whose displayed last-updated date is May 25, 2022; an actual account’s applicable agreement and version must be checked separately.
Locate scope before calculating uptime
Amazon Compute Service Level Agreement separates Region-Level SLA, Instance-Level SLA, SLA Credits, Credit Request and Payment Procedures, exclusions and definitions. The region and single-instance scopes have different conditions. Use those named sections to transcribe the relevant definition, tier, billing base and claim requirements.
The region definition concerns concurrent loss of external connectivity across the specified running instances and deployment arrangement. It is not simply a count of any application errors in one availability zone. An application’s successful response can depend on resources outside this SLA, while a particular resource outage may not disable the whole application.
Start with the account, region, resource IDs, deployment topology, applicable month and contract version. Identify which scope is actually being tested. A company-wide cloud invoice and a dashboard showing a customer journey do not provide those fields automatically.
Rebuild a fictional month
Assume a thirty-day billing period, or 43,200 minutes. After applying the explicitly stated resource definition and exclusions, suppose 120 unique minutes qualify as unavailability. This is an assumed completed eligibility assessment, not an inference from a public outage duration.
Uptime is (43,200 − 120) ÷ 43,200 × 100%, approximately 99.7222%. Retain unrounded uptime until the tier comparison; rounding it upward first could select the wrong bracket near a boundary.
| Input | Value | Evidence needed in a real claim |
|---|---|---|
| Billing-period minutes | 43,200 | Exact period and time basis |
| Unique eligible unavailable minutes | 120 | Matching resource logs and contract definition |
| Calculated uptime | 99.7222% | Unrounded calculation retained |
| Assumed applicable credit tier | 10% | Actual scope and tier checked separately |
| Eligible affected-service monthly charges | $20,000 | Reconciled billing base |
Under an expressly assumed 10% tier, the conditional credit is $20,000 × 10% = $2,000. If total cloud spending is $100,000, multiplying that total by 10% would produce $10,000 and overstate this example by $8,000. The affected-service base, not the company’s entire cloud budget, controls the arithmetic.
The example’s tier is an explicit scenario input. The actual AWS page has different region and instance thresholds; the same calculated percentage should not be moved between those tables without checking eligibility. A correct uptime fraction alone does not establish that the scenario’s 10% applies.
Reconcile simultaneous outages rather than add durations
For a separate boundary case, assume exactly two relevant instances in two availability zones. Instance A loses external connectivity for ninety minutes and B for ninety, with sixty minutes overlapping. The combined union of affected application-facing periods is 120 minutes, while simultaneous loss across both is sixty.
Adding ninety plus ninety would give 180 instance-minutes, a different unit. For a region definition requiring the specified concurrent condition, the sixty-minute overlap is the relevant candidate interval, subject to the other contract terms. Neither the union nor the sum can replace that intersection automatically.
Sixty minutes over the same thirty-day denominator yields approximately 99.8611%. The physical incident records did not change; the resource condition changed the eligible time. Keep the incident’s full customer-impact timeline and the narrower contract timeline as separate series.
Use interval identifiers and consistent timestamps. Duplicate alerts from several monitors are evidence of one interval, not additional downtime. If a monitor reports only a percentage without raw intervals, the overlap cannot be independently reconstructed. Leave the eligible duration unknown rather than choose the largest total.
Keep exclusions and evidence in the ledger
For every candidate interval, record why it enters or is excluded from the contract calculation. Application-only failures, connection problems or account circumstances require their actual causes and the applicable text to be evaluated. Do not infer contractual responsibility from a generic red status indicator.
If only some logs cover the qualifying resource population, that is an evidence gap. It does not justify treating all missing periods as either up or down. State what is observed, the missing resource or window, and which evidence could resolve it. A public status page can be useful context without proving the customer-specific eligibility calculation.
Before multiplying by a billing base, reconcile service, region, instance scope, one-time versus recurring charges and any excluded items. The AWS credit section identifies particular charge treatment; the worksheet must use the actually applicable base. Do not infer that all invoice lines containing a cloud vendor’s name qualify.
Follow the claim separately from the arithmetic
Record the current policy’s submission deadline, required identifiers and supporting logs, submission date, provider response and final credit. The AWS page also distinguishes region and instance claims for the same instance; do not assume the two credit calculations can be stacked.
A $2,000 scenario is not an approved receivable. Use states such as calculated, submitted, additional evidence requested, accepted and applied. A confirmed credit and the billing period in which it is used can differ from the incident date. Keep those dates so later accounting conclusions do not appear earlier than the evidence.
The policy’s service-credit mechanism is distinct from compensation for lost sales or an automatic cash refund. For an issuer that both buys cloud services and promises service levels to its own customers, the upstream credit and downstream obligation may have different contracts, scopes and amounts. Do not net them without the relevant records.
Use the SLA verification sheet
| Field | Obtain | Check |
|---|---|---|
| Applicable scope | Account agreement and resource map | Region versus instance and deployment conditions |
| Time | Raw outage intervals and billing period | Intersection, duplicates and time zone |
| Eligibility | Definition and exclusion assessment | Customer effect distinct from counted minutes |
| Tier | Applicable table and unrounded uptime | Correct boundary and scope |
| Charges | Detailed invoice reconciliation | Affected base, not total cloud budget |
| Claim | Submission and provider disposition | Calculation distinct from accepted/applied credit |
When reports conflict, compare scope, clock, resource population, incident cause and billing lines before comparing percentages. Preserve a named unresolved difference. Do not average application uptime with instance uptime or choose whichever report generates the largest credit.
If the applicable agreement or resource logs are unavailable, show a conditional calculation with missing fields and stop short of an entitlement conclusion. Update after corrected incidents, resource-scope changes, contract revisions, invoices or claim decisions. The final conclusion should identify which minutes and charges support which calculation, and which part still depends on provider validation or missing contract evidence.
Test the tier and charge-base assumptions separately
For a single-instance boundary, the read policy’s 99.5% monthly commitment differs from the region commitment. A 99.7222% result does not breach that monthly instance threshold. That does not evaluate any separate hourly no-charge provision or another contractual remedy; it only shows why the region’s assumed tier cannot be copied to an instance claim.
For a separate invoice branch, suppose a raw $20,000 line includes $4,000 of ineligible one-time upfront charges. If the applicable terms exclude those charges and the remaining $16,000 is otherwise eligible, the same assumed 10% tier gives $1,600. This is not a revision to the main case, whose $20,000 was already expressly eligible. Preserve raw invoice, adjustments and final base so the assumptions cannot be swapped silently.
The billing period also needs its own duration. A separate thirty-one-day period contains 44,640 minutes, and the same 120 eligible minutes imply approximately 99.7312% uptime. Do not carry the thirty-day denominator into every month or infer a changed outage from the changed percentage. Both the eligible interval and the exact billing clock belong in the reproducible calculation.
High application latency alone does not establish the contract’s defined loss of external connectivity. Preserve the performance observation, then assess the actual unavailability definition and exclusions instead of converting every slow response into an eligible minute.
FAQ
Is customer downtime automatically SLA-eligible downtime?
No. The resource definition, exclusions and evidence must match the applicable contract.
Is a calculated service credit a refund on all cloud spending?
No. The relevant billing base and claim disposition remain separate.