Documentation

How every number here is produced

Each venue is probed on the same schedule from every region: three public REST endpoints each, one request every 5 seconds, plus a WebSocket connection held open and read continuously. Nothing on this site is reported by an exchange.

Uptime

Ok checks over total checks, REST only — a stream has no "check" to be a denominator. A response counts as ok only if it was both delivered and correct: several venues report application errors inside an HTTP 200, and a venue mid-incident will happily return an empty order book.

Availability combines the regions by quorum — a venue has to fail in a majority of the reporting ones to be called down, because one region losing an exchange is a route or a geo-block. Regions with no evidence are excluded, never counted as dissent. measuredDays travels with every window and every venue row: a percentage over eight days is not a quarter.

Latency

Percentiles over successful responses only — a timeout's 5000 ms is a fact about the timeout setting, not about latency. Latency never combines across regions: an API 30 ms from France and 176 ms from Singapore is not a 103 ms API, so every figure names its vantage point and each venue's page carries them side by side.

Anything named typical is a median of daily percentiles rather than the window's own — percentiles do not compose. The exact figure over raw samples is on the venue detail response.

Streams

Connection and delivery are kept apart, because a socket open all day and silent for an hour is 100% connected and 96% delivering and only the second is about the exchange's data. Sequence continuity is checked where a venue publishes sequence numbers, and said to be unchecked where it does not.

coveragePct24h says how much of the day the other stream numbers are computed over, and probeFault is true when part of the window was up24's own fault or never arrived. A venue up24 could not hold a socket to otherwise looks exactly like a venue whose socket was down.

Venues

Venues differ in what they publish, and that is not smoothed over. Some expose a full order book where others expose a top-of-book quote; one is probed on a KRW market because its USDT book turns over about one bitcoin a day. Each venue is measured against the API its own users call.

Announcements

3 of the 15 venues publish nothing machine-readable about their own availability, which is recorded on their pages rather than left implicit. Where a venue does publish, up24 pairs its announcement with the incident by time window — a symmetric six hours either way, on that venue, and nothing else.

Nothing checks that a notice describes the fault up24 measured, so the pairing is shown with a link both ways and is meant to be judged rather than counted. When the cases up24 timestamped earlier than the venue were read by hand, every one turned out to be a different subject.

Retention

Retention: raw samples and stream health are kept 7 days and expire by dropping whole day partitions. The minute and daily rollups never expire, and neither do incidents — so uptime, latency percentiles and every incident permalink are permanent, and only the per-check and per-window evidence behind a window older than that is gone. An error breakdown on an old stream incident says so rather than reading as clean.

So a window older than that keeps its uptime, its percentiles and its incidents, and loses only the per-check evidence underneath. An error breakdown on an expired stream incident says it expired rather than reading as a clean window.

What grades an incident

Measurement is one half; the rules that turn a measurement into an incident are the other, and they are published too — every threshold with the reason it is that number, read live from the engine that is running it.

The grading rules.