Essays on AI softwareSunday, November 1, 2026Independent · No sponsors
TalkAI Tools
EssayBy The Talk AI Tools editorsNovember 1, 2026

What an uptime promise covers

What an uptime promise covers

Three nines is the most quoted number in enterprise software and one of the least informative, because the promise is not made in the units a buyer assumes. Uptime is not the share of your requests that worked.

What this note covers, in order.
What this note covers, in order.

It is the share of minutes in which the failure rate stayed under a threshold that the vendor defines, excluding the minutes the vendor has excluded, remedied by a credit against next month's bill.

GitHub Copilot's public homepage, captured automatically on October 14, 2026. Not a logged-in account; the page may have changed since.
GitHub Copilot's public homepage, captured automatically on October 14, 2026. Not a logged-in account; the page may have changed since.

We read two published service level agreements, one reliability product page and two sets of commercial terms on October 20, 2026. The gap between the headline and the definitions is where this essay lives.

Downtime is defined as an error rate, not an error

The definitions section is the whole document. On Google's Gemini for Google Cloud service level agreement, last modified March 26, 2024, the decisive line is a single sentence.

"Downtime means more than 10 percent Error Rate." Error Rate is defined there as requests returning HTTP 500 or 503, divided by valid requests.

Work through the consequence. In a month where one request in eleven failed, the error rate never crossed ten per cent, no Downtime occurred, and the Monthly Uptime Percentage was 100.

The same page sets the measurement window: a "Downtime Period" means "a period of five or more consecutive minutes of Downtime", and anything shorter "will not count".

The Vertex AI Platform agreement, last modified February 12, 2026, is stricter on both counts. There, Downtime means "more than a 5% Error Rate", and a Downtime Period is "one or more consecutive minutes".

Two agreements from the same company, three months of difference in wording, and a doubled tolerance for failure on the one that covers the assistant.

Your retries can disqualify the evidence

There is a clause in the Vertex agreement that is easy to read past and expensive to ignore.

"Repeated identical requests do not count towards the Error Rate unless they conform to the Back-off Requirements." Those requirements specify "a minimum back-off interval of 1 second" after the first error, "increas[ing] exponentially up to 32 seconds".

A client that retries immediately in a tight loop is generating failures that the agreement will not count. The measurement depends on your own code behaving correctly during the incident.

The exclusions list then removes several more categories, including errors "that resulted from quotas applied by the system" and any use "inconsistent with the Documentation".

One exclusion deserves its own sentence: errors arising from "use of a model that is beyond the recommended model lifespan described in the applicable Documentation". Staying on an older model can put you outside the agreement.

Three nines is forty-three minutes, and the remedy is a coupon

The arithmetic is worth doing once. A thirty-day month holds 43,200 minutes, so a 99.9 per cent objective permits about 43 minutes of qualifying Downtime. That is our calculation from the published definition.

What you receive if the objective is missed is set out in a table.

For Gemini for Google Cloud: 99.0 per cent to under 99.9 per cent earns a 10 per cent credit, 95.0 to under 99.0 earns 25 per cent, and under 95.0 earns 50 per cent.

The credits are "credited to Customer's future monthly bills". They are not refunds, and the maximum is capped at "50% of the amount due" for the affected service that month.

You also have to ask. Customers must notify support "within 30 days from the time Customer becomes eligible", with "log files showing Downtime Periods", or they "forfeit" the credit.

And the agreement closes the question of what else you might be owed: "This SLA states Customer's sole and exclusive remedy for any failure by Google to meet the SLO."

So the compensation for an outage is a discount on the next invoice from the supplier who caused it, claimable by you, within a month, with evidence.

Where there is no agreement, the terms say so in capitals

Two of the most used model providers make no uptime commitment at all in their standard terms, and are explicit about it.

Anthropic's commercial terms of service state that "THE SERVICES AND OUTPUTS ARE PROVIDED AS IS AND AS AVAILABLE WITHOUT WARRANTY OF ANY KIND".

The same terms continue: "ANTHROPIC DOES NOT WARRANT, AND DISCLAIMS THAT, THE SERVICES OR OUTPUTS ARE ACCURATE, COMPLETE OR ERROR-FREE OR THAT THEIR USE WILL BE UNINTERRUPTED."

OpenAI's services agreement warrants that the Services "will conform in all material respects with the Documentation" and then disclaims the rest: "SUBJECT TO SECTION 12.1, THE SERVICES ARE PROVIDED AS IS."

The same agreement flags a category many pilots run on: "Beta Services may not be supported and may be changed at any time without notice" and "may not be as reliable or available as the Services".

This is not a scandal. It is the ordinary posture of a supplier selling a metered API, and it is stated where a buyer can find it. It does mean that a dependency on a preview model has no availability promise behind it.

One vendor sells reliability as a separate product

If availability is not in the standard terms, the next question is what it costs to buy.

OpenAI's Scale Tier page answers it: "Scale Tier traffic offers a 99.9% uptime SLA and prioritized compute." The offering "is available to Enterprise customers".

The price is published in units rather than tokens. The GPT-5.5 row lists a 50,000 tokens-per-minute bundle at "$750.00 per unit/day", and each unit "is purchased for a minimum of 30 days".

Beside the uptime column sits a latency column: a 99 per cent latency SLA at more than 50 tokens per second for that model. The footnote defines the measurement as "p50 request latency on a per 5 minute basis".

A median is the right statistic for a capacity planner and the wrong one for a user. Half of all requests are permitted to be slower than the promised speed in any five-minute window and the promise still holds.

The status page is the record you can check

Where the contract is silent, the public incident history is the next best evidence, and both providers publish it.

On October 20, 2026, every component listed on Anthropic's status page showed operational, as did every component on OpenAI's and GitHub's.

The incident feeds are the more useful document. Anthropic's listed eight incidents created on or after September 20, 2026, six of them marked major impact, by our count of the published list.

OpenAI's feed listed twenty-five incidents, the oldest created on October 5, 2026, four of them marked major. That is a fifteen-day window, which says something about reporting granularity as much as about reliability.

Neither number can be compared to the other, because the vendors are not counting the same kind of event. That is the honest conclusion, and it is also the argument for keeping your own error logs.

What to check before you rely on a number

An availability figure is only meaningful alongside five other facts:

If none of those five is published for the product you are buying, you do not have an uptime promise. You have a marketing figure and a status page.

Why the number stays on the slide

Three nines survives because it is the only reliability statement that fits in a sales deck and can be audited at all. The alternative is a paragraph of definitions, and nobody has ever been reassured by a paragraph.

The problem is the same one we described in unlimited is a pricing word: a familiar number doing work its definition does not support. Uptime measures minutes under a failure threshold. Users measure requests.

What follows in practice

Write down the error rate your own process can absorb, then compare it to the vendor's threshold rather than to the headline. If your tolerance is tighter than five per cent, the agreement is not protecting you.

Then plan for the outage you will not be compensated for. The second-provider question is argued in the claim that you can always switch, and the slower version of the same risk in when a model you built on is retired.

Plan and price detail, with the dates we read it, sits in our primer on AI assistant pricing for small teams and in our subject pages for ChatGPT, Claude and GitHub Copilot, with the two consumer plans compared in ChatGPT versus Claude.

An uptime promise is a definition with a number attached. Read the definition and the number becomes useful. Read only the number and you have bought a slogan.

Sources, read October 20, 2026: cloud.google.com Gemini for Google Cloud SLA and Vertex AI Platform SLA; anthropic.com commercial terms of service; openai.com services agreement and Scale Tier page; status pages for Anthropic, OpenAI and GitHub.

Sources