How to compare availability commitments for Cloud Hosting Agreements

Compare cloud hosting availability commitments by matching each promise to the customer’s workload, deployment architecture, measurement rules, exclusions, and remedies—not by ranking uptime percentages alone. Assemble the operative contract package, extract pinpoint evidence, normalize comparable terms, and test each commitment against the same outage scenarios. The resulting availability comparison matrix should show what each provider promises, whether the proposed deployment qualifies, what evidence a claim requires, and which gaps need negotiation or business acceptance before selection.

When to use this workflow

Use this workflow when customer counsel, procurement, and infrastructure teams compare hosting proposals, review a renewal, or assess an SLA amendment. Similar percentages may cover different service layers: virtual-machine connectivity, storage access, infrastructure power, or application responsiveness.

This is a US-focused transactional workflow, not an enforceability opinion or a complete resilience assessment. Rights depend on the operative language, governing law, facts, and negotiated overrides. Technical owners must confirm that deployment and measurement assumptions match the intended production environment. The steps below are review recommendations, not generally applicable legal requirements.

What you need

Collect the master agreement, order, SLA, support terms, amendments, and dated incorporated webpages. Include relevant security schedules, data-processing terms, and any business associate agreement. Identify whether each document is proposed or executed, and flag missing attachments.

Obtain a workload description covering regions, availability zones, instance count, network dependencies, managed components, and redundancy. Ask the service owner to distinguish complete outage, intermittent errors, degraded response, and loss of a critical function.

Also obtain pricing, billing-cycle definitions, a monitoring plan, and the customer’s negotiation checklist. That checklist should identify preferred language, acceptable fallbacks, and escalation owners. Treat these as customer preferences, not presumed legal requirements or market standards.

Use the template

Use the Cloud Hosting Agreements — Availability comparison matrix. You can copy this table into your working document or spreadsheet. Create corresponding rows for each provider under each comparison topic rather than compressing an entire SLA into one score.

Assign document IDs and cite sections, pages, or table cells. For credit schedules, capture boundary symbols precisely; a working reference might be A-SLA, credit table R3C2.

The evidence field should contain a short extract or precise paraphrase. Distinguish “not present in reviewed package” from “document unavailable” and “text unreadable.” Use the gap field for uncertainties and adverse terms. Each material action needs an owner and disposition: verify, negotiate, escalate, or accept with approval.

Step by step

1. Establish the operative package and precedence

Inventory documents by provider, version, and incorporation reference. Trace precedence among the master agreement, order, SLA, service terms, and amendments. Do not assume the newest public webpage governs the purchase.

For example, the AWS Customer Agreement, sections 10 and 11.2, provides for modifications and incorporates policies, with Service Terms prevailing over conflicting agreement terms. That describes particular contract language, not its enforceability in every matter. (aws.amazon.com)

Record: document IDs, incorporated versions, precedence findings, and unresolved conflicts. Preserve reviewed webpages; a live page is not an authenticated historical snapshot.

2. Define the service and qualifying deployment

Ask engineering to map each promise to the actual configuration. Separate regional commitments from individual-instance commitments. Confirm that prerequisites will be satisfied at launch and maintained during scaling and maintenance. Preserve whether the promise is qualified by an efforts standard.

The Amazon Compute SLA illustrates the distinction: commercially reasonable efforts commitments target 99.99% monthly uptime for qualifying multi-zone deployments and 99.5% for individual instances. Unavailability concerns external connectivity; regional measurement requires concurrent loss across all specified running instances. Neither is an application-response guarantee. (aws.amazon.com)

Record: covered components, commitment qualifiers, prerequisites, planned configuration, and technical confirmation. Mark nonqualifying commitments as unavailable to the proposed deployment.

3. Normalize what counts as downtime

Extract the measurement period, denominator, outage definition, sampling rules, and start-and-stop criteria. Determine whether partial failure, errors, latency, or an inaccessible customer function counts. Distinguish time-based availability from request-success ratios: minutes of failure cannot establish a request-based percentage without request data.

For analytical context, 30 days contain 43,200 minutes. Under a simple time-based formula, 99.9% corresponds to 43.2 minutes and 99.99% to 4.32 minutes. These are comparison calculations, not contractual downtime allowances. Actual measurement rules and exclusions control.

Record: the formula, counted event, evidence source, and mismatch with customer monitoring. Identify commitments that cannot be compared directly without changing assumptions.

4. Apply exclusions to realistic incidents

Group exclusions by cause: maintenance, customer configuration, network dependencies, attacks, and other specified events. Check maintenance notice requirements, duration limits, and permitted windows. Excluded downtime still matters operationally.

The historical CyrusOne–Q2 infrastructure SLA excludes scheduled and emergency maintenance, DoS attacks, and specified customer-related outages. It provides at least seven days’ written notice for scheduled maintenance. This is a colocation example, not application-level cloud coverage or evidence of market standards. (sec.gov)

Test identical incidents against each proposal: a zone failure, provider maintenance, and a managed-dependency failure. Separate known facts from assumptions about causation.

Record: whether each incident counts, supporting clauses, disputed assumptions, and customer consequences even where no credit follows.

5. Test credits and claim feasibility

Calculate remedies using the contract’s affected-service fee base, not the entire invoice unless supported. Test every threshold immediately above, at, and below its boundary. Identify gaps, overlaps, caps, non-stacking rules, and restrictions on using credits.

The Amazon Compute SLA’s claim procedure requires a Support Center case received by the end of the second billing cycle after the incident, prescribed subject wording, incident details, resource IDs, and supporting logs or data. Missing required information disqualifies claims; regional and instance claims cannot be stacked for an instance. These are contractual conditions, not statutory deadlines. (aws.amazon.com)

Confirm that operations can retain evidence and submit it without exposing sensitive information. Do not turn billing cycles into assumed calendar days.

Record: calculations, submission channel, deadline trigger, evidence requirements, receipt proof, and claim owner.

6. Read remedies and change rights together

Review credit exclusivity, damage exclusions, liability limits, chronic-failure termination rights, and amendments together. Determine whether repeated failure supports an exit or other remedy under the full package; do not infer either from a credit schedule alone.

The CyrusOne–Q2 SLA caps monthly credits at 25% and bases calculations on provider records. Material reductions in service levels or credits permit penalty-free termination by written notice during the 30 days following amendment notice. Its referenced master agreement remains necessary to complete the remedy analysis. (sec.gov)

Record: remedy interactions, amendment exposure, missing cross-references, and proposed protections. Distinguish a chronic-failure exit request from any termination right already granted.

7. Produce the customer recommendation

Compare workload consequences, coverage, evidence access, remedy value, and unresolved dependencies. Avoid a weighted score that hides a disqualifying gap. A lower percentage covering the critical service may be more useful than a higher percentage covering only a supporting component.

Give each reviewer a decision. Engineering confirms architecture and observability; procurement evaluates credit economics; counsel resolves scope and negotiation language. State what would change the recommendation, such as confirmation of eligibility or an agreed measurement method.

Record: preferred option, approval conditions, fallback language, and accepted residual risks. Classify material rows as confirmed, negotiation required, or awaiting evidence. Assign every open issue rather than closing it to meet a commercial deadline.

Worked example

Fictional scenario: Alder Cart Systems compares Northbank Cloud and Cedar Compute for checkout hosting. All parties, documents, amounts, and clauses below are fictional.

Northbank’s N-SLA v3 promises 99.99% monthly external connectivity for a qualifying two-zone deployment. Cedar’s C-SLA v2 promises 99.9% monthly application availability, measured as 100% minus the percentage of minutes when its managed gateway cannot return a successful checkout response. Both proposals identify $20,000 in affected monthly service charges. Northbank’s routing prerequisite remains unconfirmed.

Counsel tests a 30-day month containing 50 minutes of complete checkout failure while virtual machines remain externally reachable. No maintenance exclusion applies. Under Cedar’s fictional time-based definition, availability is (1 − 50/43,200) × 100, approximately 99.8843%. Its credit band is 10% below 99.9% but at or above 99.0%, producing an illustrative $2,000 credit, subject to claim requirements. Northbank’s connectivity definition does not count the incident.

The comparison changes the selection question. Northbank’s higher percentage does not cover the tested application failure. Cedar has relevant coverage and a calculable credit, but the evidence hierarchy and missing remedy schedule prevent unconditional approval. Continue Cedar negotiations while resolving those gaps; do not declare overall superiority from one scenario.

Common mistakes

• Ranking percentages without architecture. Match each number to the deployment and covered service before comparing it.
• Treating support response as restoration. Separate acknowledgment, troubleshooting, restoration targets, and availability commitments.
• Mixing measurement units. Do not calculate request-success availability from outage minutes without a contractual basis.
• Using the full invoice as the credit base. Identify affected charges, exclusions, and caps first.
• Ignoring evidence asymmetry. Where provider records control, assess access and seek a workable reconciliation process.
• Rounding away threshold problems. Preserve boundary operators and contractual precision; flag uncovered equality points instead of silently repairing them.

Final quality check

• Every material conclusion has verified document evidence and a pinpoint reference.
• Incorporated versions and precedence conflicts are resolved or assigned.
• Engineering has confirmed deployment eligibility and covered components.
• Measurement formulas separate contractual inputs from analytical assumptions.
• Identical incidents have been tested against coverage and exclusions.
• Credit boundaries, fee bases, caps, and non-stacking rules have been checked.
• Claim requirements have an owner and obtainable evidence.
• Missing documents, negotiation points, and accepted risks have explicit dispositions.

Complete the workflow with DecoverAI

DecoverAI is the Legal Intelligence Platform for litigation and transactions. In its contract review workflow, select the customer as the represented party in Word and provide deal-specific instructions. Findings quote clauses, rank severity, locate text, and identify missing language as not present. Lawyers edit or insert suggestions as ordinary tracked changes in the signed-in Word user’s name, or dismiss findings with reasons. Tabular review supports comparison across documents; the matrix remains the team’s work product, subject to source verification and technical judgment. Book a demo to discuss this hosting-agreement workflow.

Frequently asked questions

Is 99.99% always better than 99.9%?

No. Compare covered events, deployment prerequisites, exclusions, measurement, and remedies. A higher connectivity commitment may not address the application failure that matters to the customer.

Should support commitments appear in the matrix?

Yes, when they affect incident handling or evidence collection. Use separate rows so a response target is not presented as a restoration deadline or availability guarantee.

How should we handle an unavailable incorporated SLA?

Mark it unavailable, record the incorporation reference, and assign procurement to obtain the applicable version. Do not substitute current website language without confirming that it belongs to the operative package.

What changes when the workload contains ePHI?

Where HIPAA applies, compare availability and access terms with the BAA. HHS cloud guidance advises consistency among the SLA, BAA, and HIPAA requirements, including access to ePHI. An uptime percentage alone does not resolve that review. (hhs.gov)

Sources

Source scope: October 13, 2026. Live provider pages do not authenticate the terms incorporated into a particular customer agreement.

• Amazon Compute Service Level Agreement — deployment commitments, definitions, and claims.
• AWS Customer Agreement — incorporation, precedence, and modification language.
• CyrusOne–Q2 infrastructure SLA, SEC Exhibit 10.12.1 — historical colocation agreement.
• HHS Guidance on HIPAA & Cloud Computing — guidance for HIPAA-covered cloud relationships.

This guide is general information about legal workflows, not legal advice for any matter. It was drafted and reviewed with AI assistance. The worked example is fictional. Contract rights and procedure depend on the governing law, the actual wording, and the facts, so check the cited sources and the rules that apply in your jurisdiction before relying on it.