AI Service Uptime: Check What the Promise Measures

A small creative studio needs an AI-assisted handout ready for a client workshop. The supplier advertises an impressive uptime percentage. The studio still needs an answer to a more specific question: will the complete, checked document be ready for its delivery deadline?

In this hypothetical purchase, the percentage is relevant evidence. To use it well, the studio must identify what is being measured, which service is covered and what happens when the target is missed. That reading also reveals which parts of the studio’s own workflow need separate checks.

Separate the measurement, target and agreement

Google’s Site Reliability Engineering chapter on service level objectives distinguishes three terms that help unpack a service promise:

• Service level indicator, or SLI: the defined measurement, such as the proportion of qualifying requests that succeed.
• Service level objective, or SLO: the target set for that measurement.
• Service level agreement, or SLA: the agreement that includes consequences associated with meeting or missing its objectives.

For the studio, these labels suggest three questions to put beside a supplier’s percentage: what event is counted, what threshold applies, and what response follows a shortfall? Keep the answers together. A number separated from its measurement rule is difficult to apply to a business decision.

Read the calculation before translating the percentage

The Amazon Bedrock SLA, last updated on 4 October 2023, illustrates the importance of definitions. It calculates monthly regional uptime as the average availability across five-minute intervals. Within an interval, availability concerns qualifying API requests that do not fail with the document’s defined error: a request returning error code 500. An interval with no requests is assumed to be fully available for this calculation. Exclusions also apply.

Its service-credit brackets begin below 99.9% monthly uptime. Eligible claims require a support case and supporting request logs under the stated procedure.

Read that calculation before turning the headline into an allowance of outage minutes. The treatment of intervals, requests and exclusions is part of what the number means. For your own purchase, identify the equivalent definitions in the terms that apply to your account and service.

Check which clock a speed promise uses

Google Cloud’s generative inference SLA, last modified on 30 June 2026, names the covered API methods and distinguishes uptime from a separate latency objective for qualifying Provisioned Throughput streaming use. Coverage depends on the specified models, endpoint and request conditions.

For that latency objective, generation speed is measured in tokens per second, from the first returned non-thinking token to the last. This measurement leaves the wait before that first token outside that particular clock.

For the studio, the practical question spans a longer sequence: submitting the request, receiving the answer, checking it and obtaining the finished file. Record which part a speed measure covers. A useful measurement of one stage can sit alongside a separate target for the complete job.

Identify the promise attached to your purchase

If you are buying a finished AI application, ask its supplier to identify the service agreement for that application and subscription. Where an upstream cloud commitment is cited, ask how it relates to what you are buying.

A compact review can capture five fields:

• Coverage: the named service, account or project, region and relevant configuration.
• Measurement: the counted events and the definition of success or error.
• Period: the reporting month and any shorter intervals used in the calculation.
• Qualifications: the applicable models, features, request conditions and exclusions.
• Response: the available credit, claim deadline, evidence and contact route.

Use the current document and record when you checked it. Where a field remains unclear, turn it into a specific supplier question. Compare the completed fields for the actual configurations you intend to use.

Give the studio its own definition of a completed job

The Site Reliability Workbook’s guidance on implementing SLOs discusses measures such as availability, latency, correctness and coverage. It also distinguishes the outcome users care about from the mechanism used to measure it. Measurements taken at different points can capture different parts of the experience.

For the handout workflow, I would start with three separate checks: did a response arrive, how long did it take to reach a reviewable document, and did the finished file contain the approved workshop details in the required format?

Suppose an answer arrives promptly but gives the wrong venue. Or suppose the text is correct but the studio cannot download the file. These hypothetical outcomes call for different corrections. Recording them separately helps the team explain what needs attention.

For a broader discussion, MaryChuks.com’s article on AI reliability evidence examines how to define and investigate failures across a complete system.

Put a decision point before the client deadline

Return to the fictional studio. The handout must reach the client by 09:00. The team sets 08:45 as its review cutoff and decides in advance what happens if the AI-assisted route has not produced an acceptable file.

Its alternative might be an existing template populated from approved workshop details. The team can rehearse that route, identify who completes it and check whether the remaining time is sufficient. Set the times using a rehearsal of the review and delivery work.

The key decision is when to change course. Repeatedly requesting another draft can consume the time reserved for review and delivery. Set the cutoff around the actual work needed, then record whether the alternative produced the required result.

Keep supplier evidence and delivery evidence together

After a disrupted job, preserve both accounts. Record the service events needed for the supplier’s review and the effect on the studio’s work: the document affected, the delay, the correction and the action taken. One record can support a service discussion; the other supports a decision about the workflow.

An uptime promise becomes useful when you can explain its measurement, coverage and consequences. Add a clear definition of your own finished task and a practical response to delay. That gives a business owner something concrete to manage before the next deadline.

Sources

• Google SRE: Service Level Objectives, book chapter, checked 24 October 2026.
• AWS: Amazon Bedrock Service Level Agreement, updated 4 October 2023; checked 24 October 2026.
• Google Cloud: Gemini Online Inference API SLA, modified 30 June 2026; checked 24 October 2026.
• Google SRE Workbook: Implementing SLOs, book chapter, checked 24 October 2026.