How to review service-credit claim requirements for Cloud Hosting Agreements

Review service-credit claim requirements by connecting the applicable SLA to the customer’s deployment, incident evidence, billing records, and submission obligations. Identify qualifying downtime, exclusions, the credit formula, and exactly when and how a claim must reach the provider. Record each requirement, source, owner, and unresolved dependency in a service-credit tracker. The deliverable is a claim-readiness assessment: what the customer can substantiate, which deadlines require action, what recovery remains conditional, and what should change before signature or submission.

When to use this workflow

Use this workflow when customer counsel reviews proposed hosting terms, assesses an outage claim, or checks whether operations can satisfy an existing SLA. It is particularly useful when procurement negotiated an availability percentage without testing the claim procedure with engineering and finance.

The scope is service-credit eligibility and recovery, not a complete security, liability, or exit review. Examine those provisions where they affect the claim. This US-oriented transactional guide addresses contractual procedures, not court or arbitral deadlines. Rights depend on actual wording, governing law, deployment, and facts; provider examples are neither universal rules nor market standards.

What you need

Collect the hosting agreement, order, applicable SLA, support terms, amendments, and dated incorporated webpages. Include notice, modification, and precedence provisions. Before signature, identify the draft version and treat incident questions as prospective tests.

Obtain these operational and financial inputs:

• Service names, accounts, resource identifiers, regions, zones, and deployment diagrams.
• Incident timestamps and time zones, connectivity logs, support cases, provider notices, and root-cause findings.
• Invoices, billing-cycle boundaries, affected-service charges, discounts, and invoice-receipt evidence.
• The customer’s negotiation checklist, approved fallbacks, claim submitter, engineering verifier, and finance owner.

Do not treat a live webpage as proof of earlier terms. The AWS Customer Agreement contains modification, incorporation, and precedence provisions; preserve the applicable versions rather than assuming today’s page controls (AWS Customer Agreement, §§10–11.2). Obtain a DPA or BAA where it governs disclosure of logs supporting the claim.

Use the template

Use the Cloud Hosting Agreements — Service-credit tracker below. You can copy this table into your working document or spreadsheet. Create one row per requirement or disputed dependency, rather than one row for the entire outage.

Assign stable document IDs and clause or page citations in Source / version. Keep operative extracts beside those references in the working file. Trigger / due distinguishes the contractual trigger, verified deadline, and earlier internal target.

Use Evidence / gap for log references, invoice cells, and unavailable documents. Credit basis records the eligible fee pool, band, cap, and stacking restrictions—not just an amount. Status / decision distinguishes verified, disputed, conditional, and unresolved findings. “Not present in reviewed SLA” differs from “incorporated support terms unavailable.”

Step by step

1. Establish the controlling claim package

Identify the order, SLA, and amendments applicable to the affected service and incident period. Read precedence provisions before resolving conflicting deadlines or formulas. Do not assume a negotiated order overrides an online SLA without supporting language.

Separate compute, storage, managed database, network, and application commitments. Check whether the customer contracts directly with the infrastructure provider or must claim against a reseller or managed host; do not assume upstream credits pass through.

Tracker output: document versions, service and contracting-party scope, controlling-language conclusion, and an assigned reviewer for missing terms or precedence issues.

2. Match eligibility to the actual deployment

Ask engineering to map affected resources to deployment conditions and the downtime definition. An application failure may not establish qualifying infrastructure unavailability.

For example, the Amazon Compute SLA distinguishes regional and individual-instance commitments. Its connectivity-based definition makes resource topology and concurrent failure relevant, rather than application response alone (Amazon Compute SLA, SLAs and definitions).

Apply exclusions to incident facts, not simply the provider’s event label. If maintenance is invoked, obtain the notice and test any contractual timing or delivery conditions. Distinguish verified excluded minutes from disputed minutes.

Tracker output: eligibility test, resource IDs, supported interval, exclusion analysis, and engineering’s confirmation or specific uncertainty.

3. Translate submission terms into executable instructions

Extract the channel, authorized submitter, required wording, attachments, deadline trigger, and receipt requirement. Determine whether an incident ticket also qualifies as a credit request; do not assume equivalence.

The Amazon Compute SLA requires a Support Center claim, specified subject wording, incident details, resource IDs, and supporting records. Receipt is due by the end of the second billing cycle following the incident; missing required information disqualifies a request (Amazon Compute SLA, Credit Request and Payment Procedures).

By contrast, the historical CyrusOne–Q2 infrastructure SLA requires a written request within 90 days after receipt of the invoice covering unavailability. This is a colocation example, not an application-level cloud rule (SEC-filed SLA, §II(c)).

Tracker output: trigger evidence, verified deadline, submission instructions, receipt-proof requirement, and owner. Do not convert billing cycles into assumed calendar days. Assign urgent verification where the trigger remains unknown.

4. Build a supportable evidence packet

Have engineering reconcile customer logs, provider reports, and support correspondence to a common time zone. Preserve originals and identify the source of each start and end time. Use a public status notice as corroboration, not a substitute for resource-specific proof.

Index evidence by resource and interval. Identify unavailable details and any provision making provider measurements controlling. Review the packet for confidential information, credentials, and personal data; follow applicable submission instructions and confidentiality restrictions without removing essential technical proof.

Tracker output: evidence references, timestamp conflicts, redactions, missing records, and a named gap-resolution owner. Never present estimated intervals as observed facts.

5. Verify the calculation and recovery limits

Map qualifying minutes to the measurement period and credit band. Test boundary values, rounding, excluded time, and overlapping incidents. Use a customer-prepared calculation sheet with traceable inputs and engineering and finance validation.

The Amazon Compute SLA ties credits to affected EC2 charges, excludes one-time payments, prohibits regional and instance-level stacking for an instance, and generally makes its remedies exclusive unless the governing agreement provides otherwise (Amazon Compute SLA, SLA Credits and claim procedures).

The CyrusOne example uses affected services’ monthly recurring charges, caps monthly credits at 25%, and bases calculations on provider records (SEC-filed SLA, §III).

Separately check whether recovery is a future invoice credit, refund, or another adjustment, and whether minimum amounts or account restrictions apply. Read remedy exclusivity alongside negotiated carveouts and liability provisions rather than assuming a credit resolves every outage consequence.

Tracker output: formula, invoice references, conditional amount, caps, combination restrictions, recovery form, and remedy questions for counsel.

6. Decide whether the requirements are workable

Before signature, test whether the customer can collect required evidence and use the submission channel. Confirm backup access if the sole account administrator is unavailable. Check that log retention covers the claim window.

Use the customer’s own negotiation checklist to propose targeted changes: clearer triggers, feasible evidence requirements, supplementation rights, or a dispute route for provider-only measurements. These are customer preferences, not mandatory protections.

For an existing outage, distinguish supported and disputed portions. Do not assume an incomplete or “protective” submission preserves rights where completeness is required. Escalate missing evidence promptly rather than waiting for the investigation to finish.

Tracker output: accept, negotiate, submit, or escalate recommendation, with rationale, fallback, and approving owner.

7. Close the review with a documented handoff

Issue a short assessment identifying the supported claim, unresolved exclusions, submission deadline, and recovery limitations. Assign submission and acknowledgment retention. Use the customer’s calendar or task process for internal targets; the tracker does not send reminders.

Specify the records operations should return: submitted packet, case reference, receipt timestamp, provider response, and eventual invoice adjustment. The review can close with assigned follow-up, but a claim should not be marked recovered merely because a support case exists.

Tracker output: final review decision, remaining actions, proof required, and finance ownership for confirming the credit.

Worked example

Fictional scenario. Larchmere Analytics buys managed hosting from Cobalt Quay Cloud. All parties, documents, clauses, and amounts below are invented. Signed SLA-04 defines qualifying unavailability as concurrent loss of external connectivity across two named production zones. Section 4 excludes maintenance notified in advance. Section 6 awards 10% of affected monthly hosting charges for 60–119 qualifying minutes. Section 7 requires a support-portal request, resource IDs, and connectivity logs within 20 calendar days after receipt of the relevant invoice.

Application monitoring shows 82 minutes of failure. Engineering’s logs support only 68 concurrent connectivity-loss minutes. A provider message labels the event maintenance, but the reviewed packet contains no advance notice. INV-09 lists $8,000 of affected hosting and $2,000 of unrelated storage charges. Invoice receipt remains unverified.

The review narrows the claim from an 82-minute application failure to 68 supported connectivity-loss minutes. Both reach the fictional band, but only the latter has evidence matching the definition. The $800 remains conditional on maintenance eligibility. The missing receipt record is an urgent deadline risk, not a reason to postpone preparation or assume the invoice date controls.

Common mistakes

• Starting with uptime percentages. Map service layer, topology, and qualifying downtime first.
• Treating an incident ticket as a claim. Verify channel, wording, contents, and receipt separately.
• Applying the credit to all cloud spend. Reconcile eligible charges and exclude unrelated services.
• Accepting a maintenance label as proof. Test the exclusion’s notice and timing conditions.
• Waiting for perfect evidence. Escalate gaps while preparing the packet; verify whether supplementation is permitted.

Final quality check

• Applicable documents, contracting parties, and versions are identified.
• Material requirements have verified clause or page references.
• Engineering has checked resources, topology, timestamps, and qualifying minutes.
• Exclusions are substantiated, disputed, or assigned for resolution.
• The deadline follows the actual trigger and receipt rules.
• Calculations trace to eligible charges, bands, caps, and recovery restrictions.
• Submission contents, channel, owner, backup, and receipt proof are specified.
• Open issues have decision owners; conditional amounts are not described as approved recoveries.

Complete the workflow with DecoverAI

DecoverAI is the Legal Intelligence Platform for litigation and transactions. In contract review, select the customer as represented party in Word and provide deal-specific instructions. Findings quote and locate clauses, rank severity, and identify missing language as not present. Lawyers can 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 tracker remains the customer’s work product and counsel verifies conclusions. Book a demo to discuss reviewing hosting SLA claim requirements.

Frequently asked questions

Can we calculate the deadline from the outage date?

Only if that is the contractual trigger. Verify billing cycles or invoice receipt where relevant, then record the contractual deadline separately from the internal target.

Does an application outage establish credit eligibility?

Not necessarily. Match the observed failure to the SLA’s service, downtime definition, and deployment requirements before choosing a credit band.

What if only provider records govern calculations?

Flag the provision, preserve customer evidence, and request the provider’s calculation and explanation. Assess the contractual dispute route. Before signature, consider measurement transparency and challenge rights.

Should we accept a small credit without further review?

Check the fee base and whether acceptance involves a release or affects other remedies. Escalate material exclusivity questions separately from arithmetic; do not assume either preservation or waiver without reviewing the applicable terms.

Sources

• Amazon Compute Service Level Agreement — service definitions, claim procedures, credit basis, and remedies.
• AWS Customer Agreement — modification, incorporation, and precedence provisions.
• CyrusOne–Q2 Infrastructure Availability SLA, SEC Exhibit 10.12.1 — historical colocation claim and calculation example.

Source brief cutoff: October 13, 2026. Live provider pages are not authenticated historical snapshots; retain the versions incorporated into the customer’s agreement.

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.