← Bitstamp status page

Bitstamp REST · depth degradation, 19 min on 11 SEP 2026

Bitstamp REST · depth — p95 2958ms over the last five minutes, 4.5× the 7-day baseline of 662ms — from Lauterbourg, FR and Carlstadt, US. up24 opened this incident from its own measurements of Bitstamp's public API on 11 SEP 2026 07:19 UTC. It lasted 19 min and ended 11 SEP 2026 07:38 UTC, when the component started answering again.

DEGRADEDREST · depth · https://www.bitstamp.net/api/v2/order_book/btcusd/
DURATION
19 min
STARTED
11 SEP 2026 07:19 UTC
ENDED
11 SEP 2026 07:38 UTC
VS THEIR NOTICE
NOT ACKNOWLEDGED

WHAT HAPPENED

  1. 11 SEP 2026 07:19 UTC
    up24 opened the incident at degraded.
  2. 11 SEP 2026 07:38 UTC
    The component started answering again. up24 dates the incident from this moment, not from when its clearing rule finished.

HOW IT FAILED

Over the window, 2 of 1,895 checks failed: timeout ×343, bad_body ×2.

— p50‑ ‑ p95
axis 0 – 5000ms
06:50 · 11 SEP07:29 · 11 SEP08:08 · 11 SEP

REST latency for the failing endpoint, per minute, from 11 SEP 2026 06:49 UTC to 11 SEP 2026 08:08 UTC. The gap in the line is where nothing answered.

DID BITSTAMP SAY SO?

Bitstamp publishes a status feed and nothing in it lines up with this incident. That is not proof they stayed silent; it is what their feed says.

up24 opened 189 incidents for Bitstamp in the last 90 days; 7 fall within six hours of something Bitstamp published, and the rest were never mentioned. At the median, Bitstamp's own notice came 1h 34m before up24 opened its incident. Pairing is by time alone — nothing checks that a notice is about the fault up24 measured, so the 2 that up24 timestamped first are not scoops. Every entry links to the venue's own notice so the pairing can be judged.

BITSTAMP — OTHER INCIDENTS

Measured by up24's own probe against Bitstamp's public API, btcusd against USD, every 5s. This page is generated from the incident's own rows — 2 recorded transitions — and nothing on it is reported by Bitstamp.