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.
measuredDaystravels 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
typicalis 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.
coveragePct24hsays how much of the day the other stream numbers are computed over, andprobeFaultis 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.