Investigating - [This message has been deleted, a distinct incident has been opened instead.]
Aug 12, 2026 - 04:01 UTC
Aug 12, 2026 - 04:01 UTC
Monitoring - Since the initial impact, Teraswitch’s Network Engineering team has identified the instability as a routing software failure triggered during a routine configuration change. We have removed the triggering condition and implemented safeguards to prevent recurrence. The network remains stable while we complete software upgrades and permanent remediation.
Our current timeline of events is that the instability was triggered at approximately 19:09:21–27 UTC on July 29th 2026, and lasted for ~5 minutes.
More updates and a complete RCA will be released in future updates.
Jul 31, 2026 - 14:33 UTC
Our current timeline of events is that the instability was triggered at approximately 19:09:21–27 UTC on July 29th 2026, and lasted for ~5 minutes.
More updates and a complete RCA will be released in future updates.
Jul 31, 2026 - 14:33 UTC
Identified - Teraswitch is currently working on mitigations related to this issue, although traffic issues have settled.
At this time, it appears a bulk of the high-capacity US to EU cables had a fault around the same time. Our NY to London path, which had been cut and resolved earlier today, went down again, and our Ashburn to Frankfurt path suffered an outage around the same time.
At this time, the network has stabilized and we are working to ensure any additional events are not as impactful to traffic.
Jul 29, 2026 - 19:35 UTC
At this time, it appears a bulk of the high-capacity US to EU cables had a fault around the same time. Our NY to London path, which had been cut and resolved earlier today, went down again, and our Ashburn to Frankfurt path suffered an outage around the same time.
At this time, the network has stabilized and we are working to ensure any additional events are not as impactful to traffic.
Jul 29, 2026 - 19:35 UTC
Investigating - Teraswitch is looking into general Internet Instability.
Jul 29, 2026 - 19:15 UTC
Jul 29, 2026 - 19:15 UTC
Monitoring - (This status is split off from a previous issue that was originally believed to have been related.)
Customers at LON1, AMS1, AMS2, AMS3, DUB1, DUB2, FRA2, SGP1, SGP2, TYO1, TYO2 and TYO3 experienced loss of reachability to Internet destinations, as well as to internal Teraswitch backbone destinations between affected sites. Other North American sites were not affected.
MIA1 (Miami, FL) was intentionally removed from the backbone as part of our response. MIA1 remains reachable and in service, but is currently operating without full backbone connectivity, traffic to and from other Teraswitch sites is routed over the public Internet rather than our private backbone. Customers relying on MIA1 for private backbone or inter-site connectivity should expect changed latency and path characteristics until MIA1 is reintegrated.
Cause: Teraswitch uses a default route (0.0.0.0/0) internally to signal that an edge router is able to forward traffic to the Internet. Each site normally prefers the default originated by its own local edge routers, with route attributes distinguishing a local origination from a remote one.
A default route originated at MIA1 was propagated with its metric and communities stripped and an AS-path containing only our own ASN. At this time, our understanding is that this route never existed within MIA1's routers as a valid route. A route reflector at our AMS2 site propagated this altered route into our EU and APAC markets. Receiving edge routers interpreted it as locally originated and preferred it over their own valid local default. Those routers then advertised the route to the downstream data center core, which rejected it as invalid. With no acceptable default present, the affected site fabrics stopped forwarding traffic to their own edge routers, resulting in the loss of reachability observed.
Resolution: Engineers identified the malformed route within 10 minutes of onset and removed MIA1 from the backbone to halt further propagation. Affected sites reconverged on their local default routes and service was restored at 04:16:15 UTC.
Next steps: The underlying defect, whether in the MIA1 edge routers or in the route reflector, has not yet been identified. We are working to reproduce the condition and have engaged our vendor. In the interim we are implementing policy to enforce minimal required attributes on internally originated default routes so that a malformed advertisement cannot be preferred over a valid local one. MIA1 will remain off the backbone until the defect is understood and mitigations are verified; we will post an update when it is reintegrated.
A full RFO will follow.
Aug 12, 2026 - 05:18 UTC
Customers at LON1, AMS1, AMS2, AMS3, DUB1, DUB2, FRA2, SGP1, SGP2, TYO1, TYO2 and TYO3 experienced loss of reachability to Internet destinations, as well as to internal Teraswitch backbone destinations between affected sites. Other North American sites were not affected.
MIA1 (Miami, FL) was intentionally removed from the backbone as part of our response. MIA1 remains reachable and in service, but is currently operating without full backbone connectivity, traffic to and from other Teraswitch sites is routed over the public Internet rather than our private backbone. Customers relying on MIA1 for private backbone or inter-site connectivity should expect changed latency and path characteristics until MIA1 is reintegrated.
Cause: Teraswitch uses a default route (0.0.0.0/0) internally to signal that an edge router is able to forward traffic to the Internet. Each site normally prefers the default originated by its own local edge routers, with route attributes distinguishing a local origination from a remote one.
A default route originated at MIA1 was propagated with its metric and communities stripped and an AS-path containing only our own ASN. At this time, our understanding is that this route never existed within MIA1's routers as a valid route. A route reflector at our AMS2 site propagated this altered route into our EU and APAC markets. Receiving edge routers interpreted it as locally originated and preferred it over their own valid local default. Those routers then advertised the route to the downstream data center core, which rejected it as invalid. With no acceptable default present, the affected site fabrics stopped forwarding traffic to their own edge routers, resulting in the loss of reachability observed.
Resolution: Engineers identified the malformed route within 10 minutes of onset and removed MIA1 from the backbone to halt further propagation. Affected sites reconverged on their local default routes and service was restored at 04:16:15 UTC.
Next steps: The underlying defect, whether in the MIA1 edge routers or in the route reflector, has not yet been identified. We are working to reproduce the condition and have engaged our vendor. In the interim we are implementing policy to enforce minimal required attributes on internally originated default routes so that a malformed advertisement cannot be preferred over a valid local one. MIA1 will remain off the backbone until the defect is understood and mitigations are verified; we will post an update when it is reintegrated.
A full RFO will follow.
Aug 12, 2026 - 05:18 UTC
Public Services
Operational
API
Operational
Website (teraswitch.com)
Operational
Portal (console.tsw.io)
Operational
Global Network Services
Operational
Intra-Market Connectivity
Operational
Global External Internet
Operational
Internet Exchanges and Peering
Operational
Ultra-Low Latency Connectivity
Operational
PIT1 - Pittsburgh, PA
Operational
IAD1 - Ashburn, VA
Operational
EWR1 - Newark, NJ
Operational
EWR2 - Newark, NJ
Operational
MIA1 - Miami, FL
Operational
CHI1 - Chicago, IL
Operational
DAL1 - Dallas, TX
Operational
SLC1 - Salt Lake City, UT
Operational
LAX1 - Los Angeles, CA
Operational
SEA1 - Seattle, WA
Operational
VAN1 - Vancouver, Canada
Operational
LON1 - London, United Kingdom
Operational
AMS1 - Amsterdam, Netherlands
Operational
AMS2 - Amsterdam, Netherlands
Operational
AMS3 - Amsterdam, Netherlands
Operational
DUB1 - Dublin, Ireland
Operational
DUB2 - Dublin, Ireland
Operational
FRA2 - Frankfurt, Germany
Operational
SGP1 - Singapore
Operational
SGP2 - Singapore
Operational
TYO1 - Tokyo, Japan
Operational
TYO2 - Tokyo, Japan
Operational
TYO3 - Tokyo, Japan
Operational
Operational
Degraded Performance
Partial Outage
Major Outage
Maintenance