Kraken’s public status record shows two different kinds of interruption on 30 October: an unplanned connection problem during the early UTC hours, followed by scheduled website and derivatives-platform maintenance later that morning. The distinction matters to brokers and trading clients reconstructing missing orders. A screen refusing an order during planned cancel-only mode is not the same operational event as an unexpected inability to reconnect through an API.[1][2]
The incident, headed “Spot Exchange Connectivity Issues – Web, Mobile & API (Rest & Websockets),” included an investigation message describing spot and derivatives customers having difficulty connecting and submitting orders via web, mobile, REST, WebSocket and FIX. A further investigation update was recorded at 02:55 UTC; Kraken marked the incident resolved at 03:42. Its available public entry does not identify a definitive root cause or losses incurred by customers.[1]
Two separate operational records
Kraken 30 October incident and maintenance log
| UTC | Recorded condition |
|---|---|
| 02:55 | Update: unexpected spot/derivatives connectivity investigation continuing |
| 03:42 | Unexpected connectivity incident resolved |
| 08:00–08:09 | Planned spot website and API maintenance |
| 08:03 / 08:04 | Cancel-only then post-only reopening steps |
| 08:16 | Planned derivatives maintenance completed |
The scheduled spot maintenance notice warned that order entry could be limited while systems recovered. The 08:03 update said cancel-only; the following update described post-only; by 08:06 Kraken reported all order types could again be submitted and matched, with maintenance completed at 08:09. Derivatives maintenance was recorded as completed at 08:16. These statements describe transition states, not evidence that an overnight fix was restarted at 08:00.[1][2]
Other components had their own status lines, including separate funding delays and futures-provider maintenance. A trading firm reviewing its own logs should therefore match product, API route, timestamp and failure class before attributing an unfilled or rejected order to the exchange. A client that could view a balance may still have faced a connection problem through a particular execution interface.[1]
What is not established
The status history provides incident declarations, milestones and affected channels; it does not publish aggregate failed-order counts, trade restitution criteria or a postmortem assigning responsibility. It would be inaccurate to describe this as a proved exchange-wide solvency issue or a confirmed security compromise. The reporting value is a documented timeline showing why status-page component granularity matters to institutional API users.[1][2]
Sources & further reading
- Kraken Status: incident history and updates, 30 October 2026 Kraken · 30 Oct 2026 · Accessed 31 Oct 2026
- Kraken historical incident register Kraken · 30 Oct 2026 · Accessed 31 Oct 2026