How we check

Several witnesses, one answer

For each service we collect up to four independent signals. Any of them can raise the alarm, and the most serious one that is still fresh decides what you see. A source that has gone quiet or stale is dropped rather than trusted.

Test requests we send ourselves

Where we have API access, a small robot sends a tiny streaming prompt straight to the vendor's own API every one to two minutes and times how quickly the first token comes back. A failed attempt is retried twice, twenty seconds apart, before it counts. Rate-limit replies and mistakes in our own configuration are thrown out, so they can't make a healthy service look broken.

• Down the last three checks in a row failed
• Partly down half or more of the checks in the last ten minutes failed
• Slow or glitchy at least one check in five failed, or the first token takes longer than 3 seconds and three times longer than the median of the past day

The vendor's own status page

We read official status pages every minute and look only at the parts that matter for the service in question — the ChatGPT components for ChatGPT, not everything OpenAI runs. If a page hasn't refreshed in fifteen minutes, we ignore it: a frozen status page shouldn't be able to keep a service green, or red.

Real traffic through OpenRouter

OpenRouter publishes how many requests succeed for every model on every provider. We look at a vendor's models served from its own endpoints. When at least two of them, and at least half of the set, fall under 80% success over 30 minutes while also sitting ten points below their level for the day, the service is marked slow or glitchy; under 50% on average, partly down.

If three or more vendors dip at the same moment, the common factor is OpenRouter itself, so that signal is set aside for everyone.

People pressing the button

Every service page has an “I have a problem” button. Ten or more reports within fifteen minutes, at four times the usual pace for that service, mark it as slow or glitchy. Reports alone can never mark a service as down, and each visitor is counted once per service every half hour, with a cap per hour.

Keeping false alarms out

The verdict is recalculated every 30 seconds. To return to “working”, a service has to stay clean for three full minutes, so an API that flickers between good and bad doesn't flicker on this page too.

Reading the coloured bars

The 24-hour strip has 48 bars of half an hour each; the 30-day strip has one bar per day. A bar takes the colour of the worst state seen during its period. Grey means we had no data at the time — not that everything was fine.

What we can't see

Our robots run from a data centre in Europe, so a fault limited to one country, one mobile network or one office may never reach us. We can't see your account's limits or billing. And some services, Midjourney for example, have neither a public API nor a status page; for them, visitor reports are all there is.

Where the numbers come from

isAIlive is a sister project of llmlive.ai, which operates the monitoring itself; both sites read the same measurements. This site shows only one thing — whether the tool you need works right now.

llmlive.ai →

What the words mean

• Working No source sees a problem.
• Maintenance The vendor announced planned work.
• Slow or glitchy Errors or slowness, but most requests get through.
• Partly down A large share of requests or a whole feature fails.
• Down The service fails for most people.
• No data No fresh data from any source.