Binance Futures API status

Over the 42 days of a 90-day window up24 has measured so far, Binance Futures's REST API answered 99.99% of 2,095,909 checks, with a typical p95 of 126ms and a typical p50 of 78ms. Its worst day was 01 SEP 2026, at 99.99%. up24 opened 8 incidents against it in that window — uptime counts REST checks only, and an incident is as often a WebSocket feed that stalled or a socket that dropped. Is Binance Futures down right now? →

Latency is measured from each region separately and never averaged between them — the distance is the measurement. Uptime, incidents and the 90-day bars above are the opposite: they combine every region by quorum, so one probe box losing its route to an exchange is not recorded as that exchange going down. Quorum is a counting rule and it only holds while a majority can still see the venue; where a vantage point cannot measure this venue at all, its refusals are named below and left out of every number on the page rather than being left to a vote.

US East — not measured. Binance Futures does not serve Carlstadt: 51,804 checks were refused there in the last day, since 30 Aug 2026, and none of them is a measurement of whether Binance Futures is up. They are out of this row's uptime and out of the 90-day figure. Carlstadt is refused with HTTP 451, Unavailable For Legal Reasons on every REST endpoint, on every check, while Lauterbourg and Singapore are served normally. The venue says why in the body of the refusal: “Service unavailable from a restricted location according to ‘b. Eligibility’ in https://www.bin…” — the venue names the clause it refuses under, and the URL is cut off mid-host because the capture kept 120 bytes on the day it was taken. A refusal from the venue’s own edge, not a route that failed, and not a measurement of whether the venue is serving anybody else — so a reading carrying this class is discounted wherever it was recorded, the socket’s ten-second windows included — though the refused count beside this note is REST checks only.

8 incidents over 42 measured days, grouped into 6 distinct faults. A component that fails the same way twice a week has one fault many times, not many faults, and a list that prints it once per firing hides the difference behind its own length.

WORST · 90D

BY FAULTranked by how often each fired · every occurrence links to its own page

Incidents are opened by up24's own state machine over its own measurements, not by Binance Futures's status page. One WebSocket carries every stream a venue publishes, so a dropped socket is recorded once, against the connection, rather than once per stream.

The USDⓈ-M perpetual (BTCUSDT) on fapi.binance.com, which is a different host and a different socket from Binance spot. Measured on public market data only: server time, top of book, the REST depth snapshot and the trade and diff-depth streams. Order placement, margin, the liquidation engine and funding are not measured and cannot be inferred from these numbers. Binance Futures's own note on this