Kripto borsası durum sayfası denetimi: Coinbase, Kraken ve OKX karşılaştırması

Why Status Disclosure Matters

Exchange status pages sit between marketing promises and lived user operations. When users cannot deposit, cannot withdraw, cannot place orders, or cannot see balances update, the public status page is often the first place they check. For a casual reader, the headline message may look simple: all systems are operational, partially degraded service, or incident in progress. For a more technical reader, the useful question is deeper: what does the exchange break down into components, how recent is the update, whether history is accessible, whether APIs or feeds exist, and whether the status surface distinguishes overall platform health from per-asset or per-network issues.

This distinction is especially important in crypto because the user task is rarely just "is the website up?" A centralized exchange may have a working login page and active spot markets while one chain's deposits are delayed, one asset's withdrawals are paused, one fiat method is under maintenance, or one region has account-level restrictions. A status page can disclose some of that, but not all of it. Even when the status provider returns HTTP 200, a user may still face account risk controls, KYC review, travel-rule checks, blockchain congestion, wallet maintenance, jurisdiction limits or asset-specific routing problems.

That is why this audit treats status pages as disclosure instruments rather than uptime guarantees. We checked whether the surfaces provide machine-readable status, current component state, incident history, scheduled maintenance, subscriptions or help context. We also separate verified claims from unknowns. The result is more useful than a simple winner list because exchange operations are multi-layered and status evidence is time-sensitive.

Snapshot Method

The capture used official public surfaces only. For Coinbase, the checked set included the human-readable status page plus the Statuspage API endpoints for overall status, summary, incidents and components. For Kraken, the checked set used the same pattern: the human-readable status page and the same four Statuspage API endpoints. For OKX, the checked set included the public OKX Status page and three official help pages about withdrawal failures, deposit or withdrawal suspension, and supported crypto networks.

The capture time used in this package is 2026-09-09T23:49:42.411Z. The Coinbase API status endpoint returned HTTP 200 with indicator "none" and description "All Systems Operational." Coinbase summary/components returned 174 components, and the incidents endpoint returned 50 incident records. The Coinbase summary capture showed zero current incidents and one scheduled maintenance item. Recent incident examples returned by the incident endpoint included resolved items such as delayed ATOM sends/receives and degraded derivatives positions.

The Kraken API status endpoint returned HTTP 200 with indicator "minor" and description "Partially Degraded Service." Kraken summary/components returned 830 components, and the incidents endpoint returned 50 incident records. The summary capture included active incidents and scheduled maintenance items. Non-operational samples included Digital Currency Funding as degraded_performance and multiple asset funding entries. One captured incident sample was "Moonbeam (GLMR) and Moonriver (MOVR) Funding Delays" with status "investigating." This is a point-in-time observation, not a statement about Kraken's status at any later moment.

The OKX checked pages returned HTTP 200 HTML pages. The checked status page title was "OKX Status | OKX." The checked help surfaces covered withdrawal failure, deposit/withdrawal suspension, and supported crypto or network lookup. The audit did not find a Statuspage-style public JSON endpoint on those checked OKX surfaces. That is deliberately narrow wording. It does not prove that no machine-readable OKX operational endpoint exists anywhere; it only describes what this inspection found on the named public URLs.

Coinbase: Machine-Readable and Broadly Green at Capture Time

Coinbase's status surface was the most straightforward to parse in this review because the official status page exposed standard Statuspage API endpoints. The overall endpoint gave a compact machine-readable status: indicator none and description All Systems Operational. The summary endpoint also exposed components and maintenance fields. The components endpoint returned 174 component entries in this capture.

The important nuance is that "174 components" is not the same thing as 174 independently usable products. Statuspage component lists can include groups, subcomponents, regional entries, products, currencies, networks or operational groupings depending on the provider's model. The count is still useful because it signals how much operational detail is exposed, but it should not be turned into a product-count claim. A large component tree helps monitoring and incident review only when readers understand what each component represents.

The Coinbase incident endpoint returned 50 records in this capture. That should be described as "the endpoint returned 50 incident records," not as "Coinbase has only 50 incidents" or "these are all historical incidents." The returned examples were useful because they showed the kinds of issues a headline status may hide over time: delayed sends/receives for a specific asset, degraded derivatives positions, and trading degradation for specific markets. Those examples were resolved in the captured endpoint, but they show why users should not rely only on the top-level status banner when planning operational actions.

For a user trying to deposit or withdraw, the Coinbase public status page can help answer whether Coinbase has disclosed a known platform-level or component-level incident. It cannot prove that the user's own account, jurisdiction, asset route, blockchain confirmation path or risk review state is clear. Before moving money, the user still needs account-specific confirmation inside the product.

Kraken: Deeper Component Tree and Active Degradation at Capture Time

Kraken also exposed Statuspage-style machine-readable endpoints. That gives researchers and integrators a usable structure: an overall status endpoint, a summary endpoint, components, incidents, and scheduled maintenance. In the captured snapshot, the overall status was not green. It returned indicator minor and description Partially Degraded Service.

The summary and components endpoints returned 830 components. Again, this is a payload count, not a product count. The Kraken tree appears highly granular, including a large number of asset-level funding entries. That is useful for crypto operations because many exchange issues are not universal exchange outages. They are asset-specific or network-specific funding problems. A user may be able to trade and log in while a specific deposit or withdrawal route is degraded.

In this capture, non-operational samples included Digital Currency Funding with degraded_performance. Additional samples included assets such as Akash, Babylon, Cosmos, dYdX, Fetch.ai, Initia and Injective marked degraded_performance. The captured summary also listed "Moonbeam (GLMR) and Moonriver (MOVR) Funding Delays" as an investigating incident. This makes Kraken a good example of why component granularity matters: the overall message says partially degraded, but the operationally relevant detail is about funding paths and selected assets.

For users, this means that a status page can narrow the question. Instead of asking whether Kraken is up, the better question is whether the account function, asset, chain and direction are affected. A funding degradation should be treated differently from a trading UI incident or a historical balance data delay. All of those can matter, but they affect different jobs.

OKX: Public Status and Help Context, But Different Machine-Readable Evidence in This Check

OKX had a public status page in the checked set, and the page returned HTTP 200 HTML. The checked help pages also returned HTTP 200 and provided user-facing context around withdrawal failures, deposit/withdrawal suspension and how to check supported tokens and networks. That help context matters because many user failures are not platform-wide outages. They may relate to supported networks, suspended transfer routes, compliance review, account restrictions or product availability.

The disclosure model observed in this audit was different from Coinbase and Kraken. On the checked OKX public surfaces, this review did not find the same Statuspage-style JSON endpoints used by Coinbase and Kraken. That limits automated comparison. A monitoring agent can consume Coinbase and Kraken status JSON directly. For OKX, at least within this checked surface, a reader or crawler may need to rely more on the human-readable page and help content unless another official machine-readable source is documented elsewhere.

This is not a negative reliability conclusion. It is a disclosure and automation conclusion. A page can be operationally accurate without exposing a convenient JSON API. Conversely, a rich JSON API can still omit account-specific blockers. The relevant comparison is what the public surface allows a user or monitoring system to prove. In this snapshot, OKX's checked pages could support general guidance about status, withdrawal, suspension and supported networks, but not the same structured incident/component audit performed against Coinbase and Kraken's Statuspage endpoints.

What the Three Surfaces Let You Prove

Coinbase lets a public reader prove, at least at the capture time, the top-level Statuspage indicator, component count, current summary incident count, scheduled maintenance count and returned incident records. Kraken lets a public reader prove the same categories, with more granular asset-funding component examples in this snapshot. OKX lets a public reader inspect the official status page and relevant support explanations, but this checked surface did not provide the same direct JSON component/incident evidence.

The key limitation is common to all three. Public status pages are not account-level availability systems. They do not know whether a particular user has completed KYC, whether a withdrawal address is under review, whether a jurisdiction-specific rule applies, whether a wallet risk-control system has applied a hold, or whether a deposit is waiting on chain confirmations. They are necessary context, not sufficient proof.

For traders, treasury teams and builders, the right workflow is therefore layered. First, check the public status page for broad platform issues. Second, check component or asset-specific status where available. Third, check the exact asset, network and direction inside the logged-in account. Fourth, avoid treating HTTP 200, "operational," or an empty current-incident list as a promise that every transfer route is clear.

Practical Checklist

Before depositing or withdrawing, look for the status timestamp, not only the banner. If the page is machine-readable, check both the top-level status endpoint and the components endpoint. If the issue is about a token transfer, search for that asset or network inside the component list or incident list. If the issue is about trading, distinguish trading, funding, account, API and market-data components. If the issue is about OKX in the checked surface, consult the status page and the relevant help article, then verify the supported token and network inside the account flow.

For monitoring systems, Coinbase and Kraken can be watched through the captured Statuspage-style endpoints. Alerting should not watch only overall status. It should track component groups and specific asset funding states. It should also preserve response timestamps so that stale status data is not mistaken for current availability. For OKX, a monitor should not invent a JSON endpoint based on assumptions. It should either use an official machine-readable source if documented and verified later, or treat the public HTML/help surfaces as human-readable evidence with narrower automation confidence.

Bottom Line

The captured evidence shows three different public disclosure shapes. Coinbase was machine-readable and green at the snapshot time. Kraken was machine-readable and partially degraded, with specific funding-related details visible. OKX was publicly readable in the checked surface, but this audit did not find an equivalent Statuspage JSON endpoint on the inspected URLs.

The safest conclusion is not "use one exchange" or "avoid another." The useful conclusion is operational: status pages are evidence, but only within their scope. Read the timestamp, read the component, read the incident, and then verify the account-specific transfer or trading path before acting.