Contact and corrections

A disputed measurement is reviewed within 48 hours and corrected or explained within a week, and every correction is a dated entry in the changelog.

[email protected]

If a measurement about your exchange is wrong

Write to [email protected] with the permalink of the incident, or the venue and the window you are disputing. What helps most is anything that dates the other side of it: your own monitoring for the same minutes, a maintenance notice, the region you served the request from.

You will get an answer either way. If the measurement stands, you get the evidence behind it — which endpoint, from which probe, how many checks, what the failures were classified as — and the disagreement is a disagreement rather than silence. If it does not stand, it is withdrawn.

What a correction looks like here

A withdrawn incident is retracted, not deleted. It leaves every list, every count, the feed and the API. Its permalink keeps serving, marked as retracted, carrying the reason in plain words, and marked noindex so it stops being an answer to a search. A correction that made the original claim vanish would leave a reader who saw it with nothing to check.

Every one of them is then a dated entry in the changelog, alongside every change to a grading rule, with the commit and what it moved. That page is the whole record of up24 having been wrong, and it is meant to be read before anything here is quoted.

The most common correction so far has not been an exchange's fault being overstated. It has been up24 measuring itself — a probe holding a stuck socket and reporting it as a venue's WebSocket outage for five days. That is on the changelog too, with the numbers it published while it was wrong.

Before you write: three things that are usually the answer

Uptime here counts more than an HTTP 200. Several venues report application errors inside a 200, and an exchange mid-incident will return an empty order book. A check counts as ok only if the response was delivered and correct.

A stream incident is not a REST incident. Most incidents up24 opens are a WebSocket feed that stalled or a socket that dropped, neither of which any REST healthcheck can see. That is why a venue can stand at 100% uptime with a dozen incidents against it, and both numbers are true.

Latency is measured from one place and never averaged. An API 30 ms from France and 176 ms from Singapore is not a 103 ms API. Every latency figure names its vantage point; the methodology says which, and the thresholds publish every number a verdict is graded by.

Anything else

The same address takes questions about the API, requests for a venue that is not measured yet, and anything about the data this site holds on you — see the privacy policy and the Impressum. One person reads it, so it is not instant, but it is read.