How we check if a service is down
Every minute we combine up to four independent signals for each service. Every page says which signals it used and when each one was last checked.
1. The vendor’s own status page
Every minute we read each vendor’s status page through its public data feed: the overall status, each component, active incidents with their latest update, and scheduled maintenance. Scheduled maintenance does not count as an outage. A minor issue on the status page makes the service degraded, a major issue a partial outage, and a critical issue a major outage.
Status pages are written by people, so they often lag behind the problem. We show them in full, and every incident page compares their timing with our own checks.
2. Reachability from 6 regions
Every minute, two of our 6 AWS regions request the endpoint that actually breaks for each service, such as its API or its edge network, never a marketing page. The pair rotates, so every region checks every service every three minutes. The regions are N. Virginia (us-east-1), Oregon (us-west-2), Frankfurt (eu-central-1), Singapore (ap-southeast-1), Tokyo (ap-northeast-1), São Paulo (sa-east-1).
When a check fails, all 6 regions check again at once. One failing region counts as a local blip. Failures from two or more regions make a partial outage, and failures from every region a major outage. If one of our own regions can’t run a check, that is missing data, never a failure of the service.
Some services refuse traffic from data centers. We don’t check those from our regions and rely on their status page and on visitor reports instead.
3. Real requests to AI APIs
An AI API that answers with “unauthorized” is online, but that doesn’t mean it can answer anyone. So for AI services we send a real request with our own API key every few minutes, from two regions: a one-line prompt asking for a one-word reply, on the vendor’s smallest model.
A timeout, a server error, an “overloaded” reply or an error inside a successful response counts as a failure. A problem with our own key or quota doesn’t. A failure counts only when it happens in two or more regions.
4. Visitor reports
Anyone can tell us a service isn’t working for them and say what is broken: the app, the website, the API, logging in, slowness or errors. Each network address counts once per service every 15 minutes, and a bot check filters automated reports. We store a keyed hash of the address, never the address itself, and delete reports after 3 days.
Reports are elevated when the last 15 minutes hold at least 10 reports and at least five times the usual number for the past day. Reports alone never make a service worse than degraded.
What each state means
A service takes the worst state any signal supports. It returns to operational only after three clean minutes in a row and an all-clear on its status page.
| Operational | Every signal we have is healthy. |
|---|---|
| Degraded | Slow or partly failing: a minor issue on the status page, or far more reports than usual. |
| Partial outage | Part of the service is down: a major issue on the status page, failures confirmed from at least two regions, or failed test prompts in some regions. |
| Major outage | Down for most people: a critical issue on the status page, or failures from every region we checked. |
| Maintenance | The vendor is doing announced work and nothing is failing. |
| Unknown | We have no signal for this service right now. |
Outage alerts by email
On any service page you can ask for an email when the service goes down and when it comes back. You confirm your address once, there is no account, and every email has a one-click unsubscribe. We send at most six alerts per service in a day.
What we can’t see
- Our checks run from cloud data centers, not from home or mobile networks. A problem with one internet provider, one country or one app version can be invisible to us.
- An API that answers our checks can still fail for some accounts, features or models.
- A status page is only as accurate as the vendor keeps it.
- Visitor reports depend on how many people visit, so quieter services rarely reach the elevated level.