This page explains exactly how is-down.ai decides whether an AI tool is up or down. We publish it in full because a status monitor is only useful if you can trust how it reaches its conclusions.
The two signals we combine
1. The provider’s official status page. Where an AI provider publishes a machine-readable status feed, we read it directly and map its reported state to our scale. This is the authoritative source for incidents and scheduled maintenance the company has acknowledged. Its limitation is timing: in the opening minutes of an outage, an official page may still report “operational” while users are already affected. Not every provider publishes such a feed, so for some tools this signal is simply not available.
2. An independent reachability check. Separately, and from our own infrastructure, we request the service’s public web address and measure how long it takes to respond. We check the public endpoint only. We do not sign in, and we do not call private or paid API methods. A service that answers, even with a sign-in screen or a security challenge, counts as reachable. We treat only genuine failures as a problem: a timeout, a refused connection, a DNS failure, or a server error (HTTP 5xx).
How we combine the two
When both signals agree, the status is straightforward. When they disagree, we are deliberately slow to alarm: a single failed check from our probe is treated as a blip, never as an outage. If the provider’s official feed reports no problem, the verdict follows the feed while our probe failures accumulate, and only a sustained disagreement (several consecutive failed checks) downgrades the verdict, and then only to “degraded” with a note that the signals disagree. For services with no official feed, our probe must fail several times in a row before we call a problem at all. A crowd signal from user reports is shown alongside, but it never changes the verdict on its own.
Our status scale
- Operational: the service is responding normally.
- Degraded: slower than usual, or minor issues are reported.
- Partial outage: some features or regions are affected.
- Major outage: the service is broadly unavailable.
- Maintenance: planned work is in progress.
- Unknown: we cannot currently determine the status. We show this only after three consecutive checks fail to return a clear answer, so a single blip does not flip the verdict.
How often we check
We check each service approximately every 60 seconds, around the clock. To keep pages fast and to avoid overloading the providers, the live status you see is served from our most recent stored result rather than triggering a new external check on every visit. Every page shows when it was last checked, and the figure updates as fresh results arrive.
How we measure response time
The response time shown on each page is the round-trip time of our most recent reachability check: how long the service took to answer our last request, in milliseconds. It is a single live reading, not an average, so it can move from one minute to the next. The uptime history chart uses a different figure, the average response time across all of a day’s checks, which smooths out those minute-to-minute swings.
Where we check from
Independent reachability is currently checked from one monitoring region: North America: Virginia, US. Every status page lists each active region with its own result, latency and last-check time, and we do not claim global monitoring coverage while a single region is active. A problem that affects only one part of the world may look fine from Virginia, and a network issue between Virginia and a provider can look like a provider problem when it is not; we weigh the official status source and user reports against our own check precisely to catch these cases.
Because one vantage point is limited evidence, our aggregation rules are deliberately conservative: a single failed check from one region never changes a verdict; a probe failure must repeat for at least three consecutive checks before it counts at all; and a verdict backed only by our own single-region probe is capped at “partial outage”. Calling a broad independent outage “major” requires sustained failures from at least two geographically separate regions, so until additional regions are deployed, a “major outage” verdict always comes from the provider’s own status source. If a region’s result is missing or older than five minutes, that region is shown as Unknown rather than repeating its last status.
Which signal wins? Official provider component feeds define which product surface an incident affects, and a provider-confirmed incident is always reported as such. Our probe verifies public reachability and can detect problems before a provider acknowledges them, but it never overrides a healthy official component reading with a worse verdict on its own. When the two sources contradict each other, for example the official feed reports a major outage while our probe still reaches the service, the page says “Signals disagree” and shows both readings instead of picking a winner. User reports are displayed alongside these signals but never change a verdict by themselves. A regional problem, when detectable, is described as a possible regional issue rather than a global outage.
User outage reports
Anyone can report an issue from a service’s page. Reports are rate-limited to one per visitor every ten minutes, protected against automated abuse, and stored without any personally identifying information. They are a crowd signal that complements our direct checks. Once at least five reports arrive for a service within an hour, we note on the page that users are reporting problems too. Reports add context, but they never override what our own checks find.
How long we keep data
We keep detailed, minute-by-minute check records for 60 days, which powers the recent history you see. We keep the daily uptime summaries indefinitely, so long-term reliability stays visible even after the raw records age out.
Independence and limitations
is-down.ai is independent and not affiliated with any provider we monitor. We report what our checks find, without favour. No external monitor can be perfect, and it is worth being explicit about what ours can and cannot see.
Monitoring limitations
- A reachable login or landing page does not prove that every feature behind it works.
- A web probe cannot test authenticated prompts, model responses or paid features; it only verifies that the public endpoint answers.
- Some provider status pages do not expose machine-readable feeds, so those surfaces rely on our independent checks or show Unknown.
- Regional and account-specific problems may never appear as global incidents, especially while we monitor from a single region.
- User reports are unverified crowd signals: useful context, never proof, and never enough to change a verdict on their own.
Questions about our method? Contact us.