How to read an AI service’s reliability promises

A railway timetable might say its trains run on time. That sounds clear until you ask what counts. Does a train that arrives a little late count? Does a cancelled one? Does a replacement bus?

Reliability promises for AI services have the same problem. The headline sounds simple, but the meaning sits in the definitions underneath it. This piece explains what an uptime statement usually covers, what it often leaves out, and what to ask when the wording is vague.

What an uptime statement usually covers

Most reliability promises describe availability. That is the share of time, over a set period, that the service could be reached and responded. It is usually written as a percentage.

Three details shape what that percentage means. The first is the measurement window, such as a month or a year. The second is who measures it, which is usually the provider. The third is what counts as "available", which may be as simple as the service answering a basic check.

The promise normally comes with a remedy. That is what you get if the target is missed. Often it is a credit against a future bill.

What it often leaves out

The gaps matter as much as the promise. These are the ones buyers meet most often.

Slow is not down. A service can be reachable and still answer too slowly to be useful. Many availability promises do not count that time at all.

Partial failure. Some requests may fail while others succeed. One model may be unavailable while the rest work. Ask whether that counts as downtime, and for whom.

Planned maintenance. Scheduled work is often excluded from the calculation. That can be reasonable, but you should know how much notice you get.

Where the work moved. If a site fails, traffic may be sent elsewhere. That keeps the service up, but it may break a rule about where your data can be processed. (We look at this in Data center outage: what happens when one site goes down.)

Capacity. A service can be "up" and still turn away or queue your requests because it is full. Rate limits and capacity caps are often described in a separate document.

Why AI services are harder to describe

A web page is either served or not. AI inference is less tidy. Each answer depends on a particular model, running on particular GPUs, at a particular level of demand.

So one service can behave very differently from one model to the next, or from a quiet hour to a busy one. A single percentage averages all of that away. (For why answering is its own kind of work, see AI training vs inference: two different jobs.)

This does not make uptime promises useless. It means you need to know which part of the service they describe.

What to ask when it is vague

If the wording is unclear, these questions usually bring out the detail:

1. What exactly is measured, and how often?
2. Does a slow answer, an error or a refused request count as downtime?
3. Does the promise apply to every model, or only some?
4. What is excluded, such as maintenance, your own errors or upstream outages?
5. If my work fails over to another site, will it stay inside the region I chose?
6. How do I see the measurements myself, rather than relying on a status page?
7. What is the remedy, how do I claim it, and is it capped?

Ask for the answers in writing. Nothing in this article is legal advice. If the promise is part of a contract, your own adviser should review it.

Reading the remedy

The remedy tells you how seriously the promise is meant. A credit is not compensation for lost business. It is a partial refund of what you paid for the time affected.

Check whether credits are automatic or must be claimed. Check how long you have to claim them. And check whether there is a ceiling, so you know the most you could ever receive.

If the remedy is small next to what an outage would cost you, plan for that. Your own design, such as a fallback route or a second provider, may matter more than the promise.

Records make promises checkable

A promise is easier to trust when you can check it. That means records of what was asked for, where it ran and what came back. (We describe this in AI audit trail: a receipt for AI work.)

With records, a disagreement about downtime becomes a question of reading the log. Without them, it is your memory against the provider's dashboard.

What we are building

We are not making reliability commitments in this article, and we do not publish uptime figures for Starfield here. What we can describe is the approach we are taking.

Starfield deploys standardized compute close to power, connectivity and demand, and we're building one programmable network to connect it for AI inference. Workloads are designed to be placed by policy, on latency, data residency, model and load, and every workload is designed to generate an auditable record of commitment, placement and delivery.

The aim is that you can check what happened, rather than take it on trust.

If you are weighing reliability terms for AI work, use Request capacity below.