Summary

  • Cloudflare investigated elevated overload errors affecting “Durable Objects” and possibly RealtimeKit and Realtime SFU customers in Hong Kong from 06:59 to 07:20 UTC on 19 August. It reported a fix after seven minutes and resolved the incident about 14 minutes later.
  • “Durable Objects” alone moved to degraded performance in the component record. Hong Kong, RealtimeKit and Realtime SFU stayed operational, showing why a green location indicator cannot establish the health of a stateful application path.

A green location badge and a degraded state service can both be accurate. Cloudflare's Hong Kong incident on 19 August is a compact example of why operators need to know which one they are looking at.

The official incident record opened at 06:59:19 UTC. Cloudflare said it was investigating a “Durable Objects” issue that potentially affected multiple customers in the Hong Kong region. Customers using “Durable Objects” and reliant products such as RealtimeKit and Realtime SFU might, it said, see an elevated level of overload errors.

At 07:06:33 UTC, Cloudflare reported that it had implemented a fix and was monitoring the results. At 07:20:23 UTC, it marked the incident resolved. The recorded interval was therefore about 21 minutes. Cloudflare classified the impact as minor, but did not disclose a root cause, the repair, the number of customers affected or an error-rate measurement.

The component history is as important as the clock. “Durable Objects” changed from operational to degraded performance. RealtimeKit, Realtime SFU and the Hong Kong location remained operational in the same affected-component data. The prose warned that users of the Realtime products could still encounter overload errors. This is not necessarily a contradiction: a broad component can remain available while a dependent operation fails for some calls. It is, however, a warning against treating one green tile as a complete service-level verdict.

“Durable Objects” are not simply another stateless edge function. Cloudflare's product documentation describes each object as a globally addressable instance that combines compute with private, transactional and strongly consistent storage. A logical object runs in one location and executes on a single thread. Applications use that property to coordinate shared state for chat rooms, collaborative documents, games, counters, sessions and long-lived connections.

The same property that makes the model useful defines its failure boundary. Requests for one object converge on the instance that owns its state. If that path returns overload errors, sending the call to an arbitrary healthy edge does not recreate the same consistency contract. The wider location may be reachable, and unrelated services may work, while the coordination step needed by one application remains unavailable or slow.

Cloudflare's troubleshooting guide lists several meanings of overload: too many queued requests, too much queued data, requests waiting too long, or an extreme number of calls to the same object in a short window. The Hong Kong notice did not identify any of those exact variants. It would be inaccurate to pick one, or to conclude that customer traffic caused a platform incident affecting multiple customers.

The distinction still changes the correct response. Cloudflare's error-handling guidance says exceptions marked .overloaded should not be retried immediately, because retries can add load and raise the overall error rate. That is general product advice, not a finding about the cause of this event. For an operator, it means the failure branch must distinguish an overload signal from a generic transient error before a retry loop turns a short degradation into application-side amplification.

The Realtime warning broadens the path that needs inspection without proving a media outage. Cloudflare describes RealtimeKit as SDKs and APIs for live video and voice, built on top of Realtime SFU. The SFU routes audio and video. The incident did not say whether meeting control, participant state, signalling, track management, media forwarding or another operation failed. It did not report dropped calls, lost recordings or terminated meetings. “Potentially impacted” remains the evidence boundary.

That boundary should shape monitoring. Cloudflare exposes “Durable Objects” metrics by namespace and request, with dashboard filtering for an individual object ID or name. A useful reconstruction would align those measures with 06:59–07:20 UTC: invocation errors, latency, object concentration, application-level failures and any Realtime session symptoms. Location health alone cannot supply that chain.

The incident also must be kept separate from Cloudflare's scheduled HKG interconnect maintenance later that day. The available public records establish no causal link. A shared city code is not evidence that the same device, facility, network path or change was involved.

Cloudflare's fast recovery limited the observed window. It did not answer the structural question exposed by the event: how should a customer preserve service when the consistent state holder is the part that is unavailable? The answer may involve sharding work across more object identities, bounded backoff, idempotent operations, a degraded read-only mode or an independently designed fallback. None is automatic, and each changes application semantics.

The next useful evidence is therefore not a claim that Hong Kong was “up” or “down”. It is a root-cause account that identifies the failed product boundary, the overload mode and the repair, paired with customer measurements at the object and workflow level. Until that exists, the status record proves a short regional degradation and a gap in what one green component can tell an operator—no more, and no less.

Sources