Bybit API status
OPERATIONALUPTIME · LAST 90 DAYS · ALL REST ENDPOINTS
Over the 62 days of a 90-day window up24 has measured so far, Bybit's REST API answered 99.99% of 3,073,194 checks, with a typical p95 of 704ms and a typical p50 of 656ms. Its worst day was 10 SEP 2026, at 99.88%. up24 opened 19 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 Bybit down right now? →
No successful measurements in this range yet.
| REGION | P50 | P95 | UPTIME | CHECKS |
|---|---|---|---|---|
Asia Singapore, SG | 10ms | 29ms | 100.00% | 51,807 |
Europe Lauterbourg, FR | 177ms | 227ms | 100.00% | 51,839 |
US East Carlstadt, US · shown above · 51,803 refused, not counted | — | — | not measured | 0 |
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. Bybit does not serve Carlstadt: 51,803 checks were refused there in the last day, since 30 Aug 2026, and none of them is a measurement of whether Bybit is up. They are out of this row's uptime and out of the 90-day figure. Carlstadt is refused with HTTP 403 on every REST endpoint, on every check, while Lauterbourg and Singapore are served normally. The venue says why in the body of the refusal: “The Amazon CloudFront distribution is configured to block access from your country”. 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.
Carlstadt — not measured. Bybit refuses this vantage point, so its percentages would describe the refusal rather than the venue, and they are left out below; the region table above says why. Each status pill combines every region by quorum.
REST ENDPOINTS · LAST 24H · CARLSTADT
| ENDPOINT | P50 | P95 | UPTIME | STATUS |
|---|---|---|---|---|
REST · ping 0 checks · every 5s · api.bybit.com | — | — | not measured | OPERATIONAL |
REST · ticker 0 checks · every 5s · api.bybit.com | — | — | not measured | OPERATIONAL |
REST · depth 0 checks · every 5s · api.bybit.com | — | — | not measured | OPERATIONAL |
WEBSOCKET STREAMS · LAST 24H · CARLSTADT
| STREAM | CONNECTED | DELIVERING | MESSAGES | MAX GAP | SEQ GAPS | RECONNECTS | RTT | STATUS |
|---|---|---|---|---|---|---|---|---|
WS · trade publicTrade.BTCUSDT | not measured | not measured | 80,292 | not measured | — | 2 | 229ms | OPERATIONAL |
WS · book orderbook.50.BTCUSDT | not measured | not measured | 1,479,459 | not measured | 0 | 2 | 229ms | OPERATIONAL |
BYBIT SAID · 90D
up24 opened 19 incidents for Bybit in the last 90 days. Nothing Bybit published lines up with any of them.
Bybit publishes no machine-readable status feed — no status page API, no maintenance calendar, nothing with a timestamp on it. Everything on this page is up24's own measurement, because there is nothing to compare it against.
INCIDENT HISTORY · 90D
19 incidents over 62 measured days, grouped into 8 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
WS · connection · connBybit WS — 7.1% of windows failing over the last five minutes (conn) — from Lauterbourg, FR and Carlstadt, US6×4 minMEDIAN29 AUGLAST SEEN
Every occurrence, newest first. 16 AUG 2026 → 29 AUG 2026.
WS · book · stalledBybit WS · book — 10% of windows stalled over the last five minutes (stalled) — from Singapore, SG and Lauterbourg, FR3×1 minMEDIAN27 SEPLAST SEEN
Every occurrence, newest first. 15 AUG 2026 → 27 SEP 2026.
REST · depth · timeoutBybit REST · depth — 100% of checks failing over the last five minutes (timeout) — from Carlstadt, US and Lauterbourg, FR — re-graded on 12 Sep 2026: an outage grade now needs two minutes, and this lasted 15 seconds2×15sMEDIAN12 SEPLAST SEEN
Every occurrence, newest first. 20 AUG 2026 → 12 SEP 2026.
REST · ticker · timeoutBybit REST · ticker — 100% of checks failing over the last five minutes (timeout) — from Carlstadt, US and Lauterbourg, FR — re-graded on 12 Sep 2026: an outage grade now needs two minutes, and this lasted 15 seconds2×15sMEDIAN12 SEPLAST SEEN
Every occurrence, newest first. 20 AUG 2026 → 12 SEP 2026.
REST · tickerBybit REST · ticker — p95 1251ms over the last five minutes, 4.5× the 7-day baseline of 276ms — from Carlstadt, US and Lauterbourg, FR2×10sMEDIAN07 SEPLAST SEEN
Every occurrence, newest first. 31 AUG 2026 → 07 SEP 2026.
REST · pingBybit REST · ping — p95 1286ms over the last five minutes, 4.4× the 7-day baseline of 291ms — from Carlstadt, US and Lauterbourg, FR2×4 minMEDIAN07 SEPLAST SEEN
Every occurrence, newest first. 31 AUG 2026 → 07 SEP 2026.
REST · depthBybit REST · depth — p95 1578ms over the last five minutes, 4.7× the 7-day baseline of 335ms — from Carlstadt, US and Lauterbourg, FR1×4 minMEDIAN07 SEPLAST SEEN
Every occurrence, newest first. 07 SEP 2026 → 07 SEP 2026.
REST · ping · timeoutBybit REST · ping — 22% of checks failing over the last minute (timeout) — re-graded on 12 Sep 2026: an outage grade now needs two minutes, and this lasted 50 seconds1×50sMEDIAN20 AUGLAST SEEN
Every occurrence, newest first. 20 AUG 2026 → 20 AUG 2026.
Incidents are opened by up24's own state machine over its own measurements, not by Bybit'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.