Broker status pages need different reading rules before their incident counts can be compared

The same blank calendar can mean different things

A count of visible incidents is not a comparable measure of broker reliability. Both eToro and CMC Markets publish component status, incident histories and documented application-programming interfaces. Robinhood’s former status page says it has been retired and directs customers to its support account. Interactive Brokers presents data-centre status and scheduled reset windows. The review on 10 November 2026 found different public records, not a common monitoring system.[1][2][3][4][5]

CMC and eToro both make incident records queryable

Both services expose documented incident APIs. The public incident-list endpoint returned 50 recent records for each in the retrieved responses. That response size is a retrieval window, not evidence that either provider deletes older records after the fiftieth incident. Archive pages, additional queries or pagination need to be checked before making a retention claim. An API makes capture more reproducible; it does not independently verify the events reported.[3][7][6][8]

An eToro record concerning outbound Money payments in the EU, UK and Australia illustrates the distinction between a public timeline and an outage duration. The record was created at 08:41:12 UTC on 7 August 2026 and marked resolved at 14:09:29 UTC, an interval of about five hours and 28 minutes. These are publication-system timestamps. They do not establish the precise start of customer impact or that every affected customer experienced the full interval.[8]

Robinhood moved the record to a social-support channel

Robinhood’s former status address now tells visitors that the status page has been retired and directs them to @AskRobinhood for updates. The same page can still present a statement that systems are operational and calendar dates with no incidents. That hybrid design is difficult to interpret historically. An empty date may mean there was no reported incident under the old system, that the retired page is no longer being populated or simply that updates moved elsewhere.[4]

A social-support channel can be useful for immediate communication, but it does not automatically reproduce the functions of a structured incident archive. Posts can be mixed with customer-service messages, amended, deleted or difficult to query over long periods. A researcher would need a separate capture process and a rule for identifying which posts count as incidents. Retiring the page therefore changes not only where customers look during an outage but the future auditability of operational history.[4]

CMC and IBKR disclose different kinds of operational evidence

CMC Markets maintains a conventional component-based status service with incident history. That is useful for distinguishing, for example, platform access from another service. But CMC’s component names and incident thresholds are its own. A “degraded performance” event on one provider cannot be assumed equivalent to a “partial outage” or an unposted internal alert at another. The page is evidence of CMC’s public disclosures, not a standardized dataset created by an independent monitor.[2]

Interactive Brokers’ status page presents data-centre availability and recurring reset windows. The retrieved version carried an update dated 7 November and a no-problems status; this review does not treat that page as a complete incident history or evidence that no interruptions occurred. Scheduled windows help customers understand intended maintenance, but they are a different kind of record from an event-by-event archive.[5]

What a comparable outage disclosure would require

A meaningful cross-broker comparison would need a common event definition. At minimum, each record should identify the affected legal entity and region, service component, start of customer impact, time of detection, time of public notice, mitigation time, full restoration time, severity, affected-user estimate and whether orders, withdrawals or deposits were impaired. Scheduled maintenance should be separated from unplanned incidents. A corrected or retrospective entry should remain in the archive with its revision history.[1][2][4][5]

A rolling display and a historical archive answer different questions. The retrieved CMC and eToro APIs support structured capture, while the 50-record responses alone do not establish the lifetime of stored records. A retention comparison would require retrieving older pages and testing the available history over a defined period. This review does not infer deleted incidents from a bounded response.[3][6]

Transparency and reliability are different variables

Nothing in this review establishes that eToro suffers more outages than Robinhood, that CMC is more resilient than Interactive Brokers or that a richer page guarantees better incident management. It establishes that their public evidence is structurally different. A provider can be reliable and disclose little; another can disclose extensively and reveal more problems. Customers should reward the second behaviour without mistaking disclosure volume for failure volume.[1][2][4][5]

The observed distinction is between two services with incident histories and APIs, a retired dedicated page directing users to a support channel, and an operational status board focused on data centres and resets. None supplies an independently measured, identically defined cross-broker outage rate. Customers and researchers should establish those definitions before comparing visible counts.[3][6][4][5]

Trading, payments and market data are not equivalent outages

Trading, payments and account access can be affected differently by the same event. A single operational indicator may not describe each customer function. The eToro example concerns outbound payments in specified regions, not a demonstrated interruption to trading. Its public-record interval should not be generalised to every component or every customer.[8]

Notice delay can matter as much as restoration time

Most public pages display when an incident was posted and when it was resolved. They do not always disclose when customer impact actually began or when internal monitoring first detected it. A provider that restores service in one hour but waits 50 minutes to warn customers creates a different outcome from one that posts immediately. For leveraged trading, the ability to seek another route or manage risk depends on notice.[1][2]

A robust record would contain four clocks: impact start, internal detection, public notice and restoration. The intervals reveal monitoring quality, communication speed and repair duration. Without them, a status-page timestamp can measure the communications workflow rather than the outage itself. Retrospective incident reports should correct the timeline while preserving the original posts.[6][2]

A 99.9% availability figure can be calculated per component, region, minute or user, with or without scheduled maintenance. If a broker lists many components, one degraded service may leave the headline platform marked operational. If it rolls every regional event into a single global component, the same underlying problem can reduce the published percentage more sharply. The number is meaningful only with the measurement rule.[1][2]

A rolling availability display changes as events enter and leave its measurement window. That is not necessarily a change in the underlying historical record. An API response, a calendar and an uptime percentage can cover different periods even on the same service. The relevant denominator and retrieval window should accompany any comparison.[3][6]

Customers need evidence for disputes caused by an outage

A public incident record can help align a customer’s complaint with the service and period affected. It does not establish that the incident caused a particular financial loss. Trade instructions, account records, alternative access routes and the applicable terms would also matter. A missing public entry is likewise insufficient to prove that a customer’s reported problem did not occur.[8][7]

Report an error or submit an update