SaaS SLA checklist: uptime, scope and service credits

Identify the service the document actually covers

Record the product, purchased plan, hosting region and document version. Ask which user-facing functions and interfaces are in scope. A commitment for one API or infrastructure component may leave the workflow your team needs unresolved. Keep the applicable document with the order information and ask the responsible owner to confirm that it covers the intended purchase. If the vendor points to a marketing page, request the document used for the service review as well. Record the question as open until the scope is clear.

Put the denominator beside the target

Ask whether the percentage is based on elapsed time, successful requests, eligible minutes or another unit. Record the observation point and the reporting window. A request-based target and a time-based target answer different questions, even when both say 99.9%. For a continuous 30-day time model with no exclusions, 99.9% corresponds to 43 minutes and 12 seconds of downtime; the uptime calculator reproduces this arithmetic. That example does not tell you whether a particular incident qualifies under an agreement. Keep the arithmetic and the scope review separate.

Work through a concrete incident scenario

Prepare an illustrative outage that affects the workflow you intend to buy. Ask the vendor to walk through when measurement starts, when service is considered restored and how partial failures are counted. Include an example involving a regional issue or a dependent integration if relevant. Request the evidence available to customers, such as incident timestamps or an export of the service report. Write down the observation source and time zone so the records can be compared later. Do not infer customer-specific availability from a public status page alone.

Make exclusions visible in the review

Ask the vendor to identify any maintenance, customer configuration, external network or dependency conditions that affect the calculation. For each answer, record the exact document section and an example of how it changes the counted time or eligible events. Determine who in your team will review these boundaries. A longer list of exclusions is not a score, and a missing answer is not proof that an exclusion applies. The purpose of the worksheet is to make the unresolved questions explicit before the service becomes part of an important workflow.

Capture the escalation and review process

Write down the support channel, required plan, severity definitions and information needed to open an incident. Ask how the customer receives updates and who owns the post-incident record. Separately record any credit request process, relevant deadlines and requested evidence as described in the applicable document. Do not treat an initial response target as a restoration promise. Have the responsible reviewer confirm the actual terms; this checklist neither interprets entitlement nor calculates compensation. The calculator converts a time-based percentage only.

Connect availability to the operating plan

Ask the business owner what the team would do while the service is unavailable. Identify the work that can wait, the tasks that require an alternate process and the information needed to resume. Rehearse that process with a harmless sample rather than interrupting a production service. Assign responsibility for keeping the vendor contact and internal escalation record current. Revisit the review if the product, region, integration or critical workflow changes. An approved document from the original purchase does not automatically answer a new operating question.

Your working checklist

The download contains these questions plus blank fields for your answer, evidence URL, review date, owner, due date and decision. Complete it in your own spreadsheet.

1. Service scope

   Which product, plan, region and functions does the document cover?

   Ask for: Applicable document and order scope.

2. Indicator

   Is availability measured in time, requests or another unit?

   Ask for: Metric definition and observation point.

3. Window

   What measurement period and time zone apply?

   Ask for: Reporting window definition.

4. Outage

   How are start, recovery and partial failures counted?

   Ask for: Worked incident example.

5. Exclusions

   Which conditions change the denominator or counted failures?

   Ask for: Document sections and examples.

6. Evidence

   Which customer-visible records support an incident review?

   Ask for: Sample incident and service report.

7. Escalation

   What support channel, severity and update process apply?

   Ask for: Support procedure for the intended plan.

8. Credits

   What request process, evidence and deadline does the document describe?

   Ask for: Applicable credit procedure.

9. Continuity

   What will our team do while the workflow is unavailable?

   Ask for: Internal operating plan and owner.

Source and scope

Google’s SRE book distinguishes service level indicators, targets and agreements, and discusses selecting measurements that reflect user needs. The procurement questions and incident-review worksheet here are our editorial tools, not a contract interpretation.

Google SRE: Service Level Objectives. Reviewed 2026-10-02.