How to read exchange API uptime and incident records
Uptime describes the share of successful requests to particular endpoints over a particular period and network route. It does not establish whether you can place an order, withdraw funds or trust a venue with assets.
An incident opens after 2 consecutive failed probes to the same endpoint and closes after 2 consecutive successes.
Calculate the request success rate
If 998 out of 1,000 eligible requests succeed, availability is 99.8%. Clearly identified regional restrictions that are excluded should be counted separately, not hidden in the denominator. This site probes public endpoints about every 15 seconds and checks expected response content as well as HTTP status. A 200 response can still contain an application error.
Worked example · not a live quote
2Isolated failure
4–5Consecutive failures confirm an incident
6–7Consecutive successes close it
A failed request is not automatically an incident
An incident opens after 2 consecutive failed probes to the same endpoint and closes after 2 consecutive successes. Scattered failures can reduce availability without opening an incident. A brief interruption may appear in one sample, or fall entirely between probes. Multiplying failed requests by the polling interval does not yield an exact outage duration.
Check location, duration and service scope
A known regional block differs from a general connection failure. HTTP 403 alone does not establish a country restriction. Results from one location describe that route; a different provider or region may see something else. Several hours of data provide less evidence than months of observation. Market-data availability does not directly test order execution, cancellations, liquidations, deposits or withdrawals.
Availability and speed answer different questions
An endpoint may succeed on every request while responding slowly. Median latency and the slower tail need their own interpretation and aggregation method. Official incident reports may cover different services and regions, so use them as complementary evidence rather than assuming either source describes the entire exchange.
When you see an anomaly
- Read the observation period and sample count.
- Identify the endpoint and whether failures are isolated or consecutive.
- Compare with the venue’s official status page and affected services.
- Check your own connection and account order status.
Related reading: How to compare funding rates: intervals, direction and position costs · Clock offset and quote age: how to interpret timing data · Market-order costs: trading fees, spread and average fill price
Rules and sources
Coinbase · Status · Measurement method · About this site
These examples are hypothetical, not live prices. Check venue rules and account records for actual charges or execution.
Other guides
How to compare funding rates: intervals, direction and position costs
Compare the same perpetual contract and settlement currency, then check the interval and whether you are long or short. An identical percentage can produce different payments when settlement schedules differ.
Clock offset and quote age: how to interpret timing data
A fast response can contain an old quote. Round-trip latency, clock offset and quote age describe different parts of a request. Mixing them can make a clock mismatch look like a delayed market feed.
Market-order costs: trading fees, spread and average fill price
A fee schedule covers only part of an execution comparison. Price deviation depends on direction, size and available depth. Keep that estimate separate from your account’s trading fee and use the same benchmark across venues.