How isuptime works

1. A scheduled job asks every provider for its current status feed.
2. eleven different response formats are parsed into one shape.
3. Each provider's own wording is mapped onto one of four states.
4. An amber or red verdict is weighed against how much of the service is actually affected, and softened if the provider is flagging more than its own components support.
5. The result is written to history, whether or not anyone is looking.
6. Uptime is the share of those recorded checks that were not an outage, over a rolling 30 days.
7. Incidents and affected components are fetched separately, per service, on demand.

isuptime does not test the services itself. It does not open a connection to GitHub and try a push, or send a prompt to an API to see whether it answers. It reads what the provider publishes about itself, which is a deliberate choice with a real cost — covered at the bottom of this page.

There is no standard for that. 89 of the 102 services here publish a Statuspage-style JSON document; the remaining 13 publish something of their own, and 7 of those do not publish a current status at all — only a list of incidents, from which the current state has to be inferred.

Every request has a ten-second ceiling, and a page render will wait no more than nine seconds for the slowest provider before reporting that one as unreachable. A feed that could not be fetched is recorded as unreachable rather than as an outage — a request we failed to make is not evidence about the service behind it.

Providers describe themselves in their own vocabulary: “minor”, “critical”, “SERVICE_DISRUPTION”, “HASISSUES”, a colour, an RSS headline. To compare forty-four services on one screen, all of it has to collapse into the same small set.

Operational

The provider is not reporting a problem. Not the same as “this definitely works”.

Degraded

Slower or partly impaired, but working. Counts as up when uptime is calculated, because the word on the card is uptime.

Partial outage

Something is genuinely broken, but a meaningful part of the service still works.

Major outage

The provider is reporting a severe, broad failure.

Some information is lost in that collapse, which is why each service page also quotes the provider's own description verbatim underneath the verdict.

This is the part that most distinguishes what isuptime reports from simply repeating a headline, and it exists because repeating the headline turned out to be wrong often enough to matter.

A Statuspage aggregate indicator describes the worst thing currently happening, not how much of the service it touches. Those are very different claims. Elastic publishes a component for every combination of product, cloud provider and region — hundreds of them — and a problem confined to a single AWS region left its headline reading “Partial System Outage” for months. Taken literally, that renders as Is Elastic down? Yes, which was untrue for essentially every user.

Cloudflare is the sharper case. Its status page lists individual edge locations alongside its products, and there is almost always a point of presence somewhere — Guam, Arica, Baghdad — in maintenance or routing around a fault. That is an anycast network behaving exactly as designed. But it holds the aggregate indicator amber, and isuptime was reporting “Cloudflare is Degraded” directly against Cloudflare's own green “All systems operational”, on the strength of a number Cloudflare itself files under a separate tab.

So the verdict is checked against two things before it is published:

• How many components are actually affected. Below a tenth of them the damage is a corner of the service; above half it is the service. Grouping rows and components in a planned maintenance window are excluded from the count — announced work is not damage, and counting container rows alongside their children double-counts every fault underneath them.
• Whether the provider has an incident open. With one open, the provider's own flag largely stands, because a provider mid-incident often raises the flag before it has finished marking up which pieces are down. With none open, a small blast radius can soften the reading all the way to operational.

Two limits keep this honest. It only ever softens a verdict — isuptime never claims a provider is in worse shape than the provider says. And it softens by at most one step, so a service flying a major-outage flag with no incident posted is still reported as degraded, not waved through as fine.

The obvious way to build this is to check the providers whenever somebody loads the page. It is also wrong, and wrong in a way that is invisible until you look at the resulting number. Traffic-driven sampling means the uptime figure measures the hours when people happened to be watching. A quiet night produces no data, and no data reads as “nothing happened” rather than “everything was fine” — while an outage big enough to send people looking gets sampled far more heavily than a calm afternoon.

So a scheduled job does the checking and writes the history, on its own cadence, independently of traffic. A page load reads that history; it does not contribute to it.

The same job publishes a snapshot that page renders can serve directly, which is what makes a cold visit fast instead of making the first visitor wait out a fan-out across all 102 providers. If the scheduler itself stops, that snapshot is treated as stale after two missed runs and pages go back to fetching live — a dead scheduler should cost you speed, not correctness.

The figure on each card is labelled No outage reported, not uptime, and the distinction is the point. It is the share of recorded checks in which the provider's own feed was not reporting an outage, over a rolling 30-day window. Uptime, as the word is normally used, means the fraction of time a service actually worked — which is not something that can be derived from reading a status page. Three decisions inside that sentence are worth spelling out, because they are the difference between figures that look similar and mean different things.

• Degraded counts as up. The alternative — scoring only fully-green checks — asks a different and much harsher question. A provider that leaves one low-severity incident open scores zero on every check for as long as it stays open, which is indistinguishable from being hard-down all month. That is how Cloudflare, with no unresolved incident on its own page, once read as 0.00% uptime here. A degraded service is impaired, not down, and the word on the card is uptime.
• Unreachable checks are discarded, not counted as failures. If a provider's feed could not be read, that says something about the network between here and there, not about the service.
• It is our checks, not the provider's SLA. This number is not comparable to a contractual uptime commitment, and it is not measured the way one is.
• It is not comparable between providers. Because degraded counts as no-outage, only a provider's most severe state costs it anything — and each of the eleven formats draws that line somewhere different. Slack only registers here when it declares a critical incident; its ordinary active incidents count as degraded. Google and YouTube only register when Google posts a public incident naming the product. A provider publishing hundreds of components will show far more variance than one publishing a single flag. Read the number against the same provider over time, not against a different one.

Two consequences follow. A service can show 100% here after a genuinely bad week, because a month of degraded performance is not an outage. And a provider that leaves a real outage open for weeks — some do, for a single region — will show a low figure for the whole time it stays open.

Incident history and the list of affected components come from separate feeds, fetched for one service at a time when its page is opened. That is a deliberate narrowing: the page used to request the full cross-service report and discard everything but the one service it was about, which cost roughly eighty upstream requests to display the contents of two.

Incidents are shown for the last 30 days, newest first, and every link points back to the provider's own incident page. For AWS, where each RSS entry encodes a service and a region, the region is parsed out so regional impact can be shown separately.

All of the above sits on one foundation: providers write their own status pages. That is the ceiling on how good this can be, and no amount of processing raises it.

• A service can be visibly broken for an hour before its status page acknowledges it. Some incidents are never posted at all.
• Most status pages report on the platform, not on your account, your project or your region. Rate limits, expired credentials, quota exhaustion and permission changes all produce failures that look exactly like an outage and appear on no status page.
• Coverage is uneven. A Statuspage provider publishes components, incident history and maintenance windows; a provider with a single aggregate flag publishes one bit. Both render as one card here, and the card cannot show detail that was never published.
• Green means the provider is not currently reporting a problem. It does not mean the service definitely works for you.

Each service page carries a section on what to check when its provider is green and you are still stuck, because the answer is different for every one of them. If something here looks wrong — a service misreporting, a feed that has moved — please get in touch.