Is TCPShield down?

At approximately 03:55 UTC, we performed a hardware replacement at our Tokyo location to resolve a long-standing issue caused by faulty DRAM, which had been causing the affected server to crash roughly every 12 hours. The replacement was completed in about 45 minutes, and production traffic was shifted back onto the new hardware as of 04:45 UTC. We do not anticipate any further degradation or maintenance windows for Tokyo and will continue to monitor closely.

Traffic across all services in Tokyo has remained stable since the replacement. We are marking this incident as resolved.

Our Seoul location is currently experiencing an issue with its optical transceiver resulting in traffic loss. Traffic has been automatically diverted to Tokyo until this component is replaced. We will keep this status updated as it progresses.

The spare optic has been enabled and traffic has been restored to the location as of 04:12 UTC. Traffic previously on Tokyo has moved back to Seoul.

We are investigating an anomaly that occurred within the GSL backbone at 13:23 UTC. Traffic has since recovered after 1 minute, with minor residual latency of approximately 5ms.

Cloudflare and OVH routes are unaffected. We will post a further update as soon as more information becomes available.

The previously reported latency increase has resolved as of 16:46 UTC following re-convergence on the backbone. We await root cause from the network team.

We are currently investigating elevated error rates in US East, US West, and AU, where some logins are failing to process. The root cause has been identified and we will post further updates as remediation progresses.

A fix has been implemented and we are monitoring the results.

A long running TCP flood caused connection state tables to fill in some locations, resulting in intermittent login and ping failures. The root cause of the excess state allocations has been identified and fully remediated as of 01:23 UTC. All regions are operating normally and we will continue to monitor closely. If you are still experiencing any issues, please open a support ticket and our staff will be happy to assist.

Between 07:43 and 07:46 UTC, our Frankfurt network experienced intermittent packet loss due to attack traffic leakage. The root cause was quickly identified as a single destination IP had been configured with a weaker mitigation profile, allowing a portion of attack volume to bypass filtering. The affected IP was reconfigured immediately. As a precaution, we also completed a full audit of all public-facing IPs to ensure consistent mitigation posture across the fleet. No further impact is expected.