How much time does a decimal place represent?

Over a thirty-day month there are 43,200 minutes. One per cent of that is 432 minutes, a tenth of a per cent is roughly 43, and a hundredth is about four. Figures that look nearly identical differ by hours of unavailability.

Why does our experience differ from the status page?

Because the vendor measures their own service and you experience the whole path, including the network in between and the specific kind of requests you make. Their measurement can be entirely accurate while yours is much worse, with neither party being wrong about anything.

What should we measure ourselves?

The path your application actually uses, from where it runs, doing the kind of request it really makes. That is the only figure that includes everything between you and them, and it is the one to have in hand during a disagreement.

Glossary

Uptime

The share of time a service is actually available, usually published as a percentage and rarely measured the way a customer experiences it.

In plain terms

How much of the time the service is working. The number looks precise and hides three questions: who measured it, what counts as working, and whether the vendor has promised anything about it or is simply reporting.

Why it matters

Because it is the number a business case rests on and the one least likely to describe what your users will see. The published figure, the contractual promise and your own experience are three separate things, and only the third is the one people complain to you about.

How it works

The decimal places are worth knowing in minutes. Over a thirty-day month there are 43,200 minutes, so one per cent is 432 of them, a tenth of a per cent is about 43, and a hundredth is about four. That is the entire difference between figures that look almost identical.

A published figure and a contractual commitment are different things. The first is a report about the past and the second is a promise with a remedy attached, and the remedy is usually a credit rather than compensation for what the outage cost you.

What counts as available is defined by whoever is measuring. A service responding to a health check while returning errors to real requests can be recorded as up, so the definition matters as much as the number attached to it.

For AI services the sharper problem is that up and useful are not the same. A model responding slowly, returning shorter answers, or failing on the longer requests is degraded in ways nothing in an availability measure detects, and the experience for users is indistinguishable from an outage.

Your own measurement is the only one that describes your experience. A check that exercises the actual path your application uses, from where it runs, is the only figure that includes the network between you and them and the specific things you ask for.

The useful planning question is not the percentage but the shape. Whether the missing time arrives as one long outage or as scattered minutes changes what you have to build, and two services with identical figures can demand completely different designs.

Three numbers people treat as one

The second line of the right-hand column is the one specific to these tools and the one no measurement scheme currently handles well. Traditional availability has a clean definition because the failure is binary: the request either completed or it did not. A model that has quietly become less useful fails no request, triggers no alert and appears on no status page, while the people relying on it can tell within an hour that something has changed. The only defence available today is unglamorous and worth building anyway: keep a small set of requests whose good answers you already know, run them on a schedule, and compare. That is a handful of examples and a job that runs hourly, it costs almost nothing, and it converts a vague sense that the tool has got worse into a dated observation you can put in front of somebody. Without it, an entire class of degradation is invisible to everybody except the users who stopped trusting the tool and did not say so.

Seen in the wild

A model responding normally while producing noticeably worse answers, with nothing reported.
OpenRouter
An automation failing at a step whose provider recorded no incident at all.
Make
A self-hosted model where availability is unambiguously your own responsibility.
vLLM

Common misconceptions

People assume

A published percentage is a commitment.

In fact

It is usually a report. A commitment is a contractual term with a defined remedy, that remedy is generally a service credit, and a credit rarely resembles what an outage actually cost the business relying on it.

People assume

If it is up, it is working.

In fact

Availability measures whether responses come back, not whether they are any good. A model returning worse answers than yesterday is fully available and entirely unusable for the job, and no status page has a colour for that.

Questions

How much time does a decimal place represent?: Over a thirty-day month there are 43,200 minutes. One per cent of that is 432 minutes, a tenth of a per cent is roughly 43, and a hundredth is about four. Figures that look nearly identical differ by hours of unavailability.
Why does our experience differ from the status page?: Because the vendor measures their own service and you experience the whole path, including the network in between and the specific kind of requests you make. Their measurement can be entirely accurate while yours is much worse, with neither party being wrong about anything.
What should we measure ourselves?: The path your application actually uses, from where it runs, doing the kind of request it really makes. That is the only figure that includes everything between you and them, and it is the one to have in hand during a disagreement.